Комментарии 160
Домашним облаком. Правда это не решает проблем социальщиков и блоггеров.
Я генерирую контент, а они в обмен встраивают рекламу. На мой взгляд довольно равноценный обмен.
И я не считаю, что хранение пары тысяч фоток в наше время стоит 5 баксов в месяц
Я генерирую контент, а они в обмен встраивают рекламу. На мой взгляд довольно равноценный обмен
Ну как бы да, с другой стороны, им виднее, равноценный он или нет. Стоимость хранилища где-то $25/терабайт не считая обслуживания и электричества, раз в три-пять лет они наверняка хранилище обновляют. Приносит ли реклама от просмотра ваших фотографий Фликру такую сумму? Думаю, нет. Скорее всего этот терабайт как раз и был изначально «заманухой», чтобы убедить пользователей переехать на Фликр, а потом, установив платные подписки, заставить некоторую часть из них там и остаться.
Я храню там, допустим, несколько тысяч жпегов — зачем мне терабайт? Я думаю большая часть пользователей такие же объемы хранит. Пусть это 1-2-3Гб. Это стоит 50 баксов год, серьезно? Облачные хранилища предлагают гораздо большие объемы вообще бесплатно. Фликр при этом еще и рекламу вкрячивает
Напомню, что ютуб, кроме бесплатного хранения контента, еще и делится доходами. А видео куда тяжелее фоточек
Во-вторых, видео смотрят все. На ютубе огромное количество посетителей, ещё более огромное количество просмотров. Это река денег от рекламы. Что может предложить фотохостинг посетителю? Как много времени вы и ваши знакомые проводят за просмотром фоток (с рекламой) на фликре?
Это вы нынешних «видеолюбителей» не знаете. Видео делается десятками гигабайт и загружается всё подряд. Большая часть видео имеет единицы и десятки просмотров.
Так с просмотра конкретно этих никому не интересных видео Ю-Туб ничем и не делится с загрузившими их.
За них платят (дотируют) загрузившие качественное видео, имеющее большое количество просмотров.
Так видеоконтент же, во-первых, генерируется куда меньшими объемами, чем фоточки.Ой, не соглашусь с вами. Как минимум Вы не учитываете, что ютуб хоть и конвертирует-уменьшает видео, но также создаёт его копии в разном качестве, что по сравнению с фотками гораздо ощутимее преумножает объём контента. А кроме того, есть немало приватного видео, доступного по ссылке, а не через поиск, или находящегося вообще в закрытом доступе.
Штучные экземпляры? Видео — это нынешний тренд, молодёжь не удивить фотками, все готовы снимать всё и вся, людям уже банально лень что-то напечатать и снабдить фоткой, когда можно наболтать этот текст на камеру сразу с демонстрацией чего-либо. Зачем любителю десять минут сто раз фоткать котика, когда можно 10 минут снимать его?
По одному из подсчётов, в год на ютуб может загружаться 100 петабайт видео. В 2006 году размер хранимого видео оценивали всего лишь в 45 терабайт.
Иными словами. Привёз с Камчатки 1300 фотографий. Потратил 5 недель и 140 часов, чтобы отобрать 300. Потратил ещё столько же времени, чтобы отобрать и обработать 50-75 фотографий для условного «Я-фото» или «Фликра». Потом привязал всё к карте, расставил метки, каждой приличной фотографии придумал название, иногда интересное. Получил комментарии, приобрёл фоловеров, посмотрел их работы, с кем-то подружился…
Теперь у меня есть альбом, в нём я вижу, что заинтересовало людей вообще, что думают друзья. Альбом я могу посмотреть через 2-5-10-20 лет, оценить своё развитие. Альбом могу показать кому-то всегда. Могу скачать в оригинальном качестве. Могу показать на стороннем сервисе.
Это обещания. А на практике всё потраченное время спущено в могилу. Психологически это тяжело. Поэтому приходишь к двум PortableHDD зеркальных с женой.
Короче, мир не совершенен, и, возможно, ему требуется какой-то закон о страховании и переносимости облачных архивов (с разумными ограничениями).
PS/ GoogleФото, VK и прочее — это, конечно, хорошо (и тоже без гарантий). Но нормальный jpeg с далеко не идеального кропа уровня Canon 60 занимает 10 МБ, а не 570 кБ. Сейчас на мониторе этого, может быть, и хватает, а когда стандартом станет телевизор 8K, как вы отнесётесь к этим потерям?
Вариантов много, исследования на месте не стоят. Пирамидальное избыточное кодирование для хранения (почти как в ceph) плюс асинхронный BFT протокол заточенный под хранилище (а не SMR) вполне может и взлететь… https://www.csee.umbc.edu/~hbzhang/files/beat.pdf
Если программеры соберутся пилить распределенную децентрализированную сеть для фотографов то я б принял участие в разработке GUI.
В такой сети часть участников сети будут донорами места для фотографий других.
Иначе — зачем?
Обязательно будут. Причем можно квоты друзьям выдывать или тем, кто тебе нравится как автор. Ибо там треша навалом.
Я к тому, что это не халява, как сейчас.
Активных генераторов контента намного меньше, чем пассивных его потребителей. Поэтому, если потребители будут выделять немного места, на них это никак не скажется, по сути, та же халява будет, а вот генераторам — будет много места.
Но, конечно, это касается именно социальных систем. С простым взаимным хранением приватных фоток так не получится. Поэтому никак не взлетают децентрализованные системы облачного хранения, типа Sia, Storj и т.п. С ними пользователи видят, что теряют больше, чем приобретают. На каждый гиг своих данных в облаке нужно хранить, грубо, 3-4Гб чужих данных. Для большинства это неприемлемо.
Активных генераторов контента намного меньше, чем пассивных его потребителей
Генераторов оригинального качественного контента — да, конечно.
Но копировщиков «посмотри какие няшки эти котики» или «красивая девушка и брызги воды» — полным полно. Поглядите на соц. сети. Сами они эти фото не делают, конечно же.
Генераторов первого типа вообще ничтожное количество :) Но даже копировщиков второго типа всё равно на поряд-два больше, чем читателей. Как Вы пишите — поглядите на соцсети :)
Но даже копировщиков второго типа всё равно на поряд-два больше, чем читателей
Поэтому такая система работать не будет.
Опечатка :) Пишу с телефона на ходу. Очевидно, что речь о том, что читателей несравнимо больше, чем даже копипастеров. И так на всех популярных ресурсах. Случаи, м когда копипастеров больше — это когда автор копипастит на селфхост, который никто не читает :)
А говоря о практике, в том же ZeroNet, где людей вообще крайне мало, мой отдельный блог, как раз для всякой копипасты (чтобы не засорять основной), раздают сейчас, как минимум, 50 нод. По-моему, вполне достаточно для надёжного хранения :)
Очевидно, что речь о том, что читателей несравнимо больше, чем даже копипастеров.
Насколько больше?
Сколько именно добровольцы должны предоставить своего места в обмен на… на что кстати в обмен?
Как показывает история с торрентами — все грустно. Хорошо работает только с самыми популярными фильмами.
Чуть чуть не современно, чуть чуть не мейнстрим — и уже 1-2 на раздаче всего-то
Tahoe_LAFS требует активных участников, обладающих недюжинными познаниями в IT. У меня на форумах несколько тысяч активистов. Я долго пытался хоть кого-то сподвигнуть на совместную работу с системами, требующими совместной активной поддержки, от btsync/rslsync до Tahoe-LAFS. Эффект ровно ноль. Какая-то минимальная активность (десяток человек) возникла только при агитации за ZeroNet. Именно потому что там от пользователей не требуется активности. Достаточно установить и использовать. Но даже этот десяток, конечно, мизер.
Все эти координаты, теги, пользователи и их потраченное время для гугла оказались не важными.
На кладбище проектов Google и без Panoramio много социальных систем. Сейчас, вот, закапывают Google+ — это явление будет даже покруче удаления Flickr.
Можно всерьёз сравнивать несчастных 90 млн. юзеров полунищего Flickr с мощью Google, который прединсталлировал Google+ двум с лишним миллиардам пользователей? :) Провал Google+ — это самый эпичный провал менеджеров последнего времени. Круче будет только если закроют Facebook :)
Вики пишет о 540 млн. аккаунтов. Тут надо ещё учитывать, что и у Flickr далеко не все 90 млн. аккаунтов были активными. И то, что будь у G+ хоть 1 млн. пользователей, это уже было бы эпичным провалом Google :) Потому что провалить соцсеть, имея такое количество потенциальных пользователей — это надо очень постараться :)
Может оказаться что дешевле не платить каждый год сумму которая может и поменяться (и надежнее, с учетом таких вот сюрпризов) купить ту же Synology в двухдисковом варианте и настроить (или попросить настроить) PhotoStation. И да, шарить фотки в Facebook тоже можно. Меняющих все вообще обновлений — нет. Поддержка — много лет а потом — имеем просто NAS без оффподдержки и обновлений но который работает.
Да, нужно настроить все один раз + по хорошему надо что-то решить с бекапами.
по хорошему надо что-то решить с бекапами..
Если данная ситуация в модель угроз входит то есть официальные варианты (штатный HyperBackup в помощь)
- ЕЩЕ один Synology (минимально дешевый) где то (у родителей) и бекап через интернет (инкрементальный конечно)
- Если нет родителей или их тоже ограбить могут одновременно — C2, недостаток — оно денег стоит. Если реально данных которые нужно бекапить больше терабайта — 69.99 EUR/Tb/год. Если меньше — то с ценами проще. Клиентское шифрование разумеется поддерживается. И разумеется бекап не только PhotoStation
- C2 не устраивает? Можно в Dropbox/Google Drive (ну а вдруг у вас терабайт с корп-аккаунтом), да хоть в S3-совместимое хранилище например от того же Selectel'а или любой rsync-совместимый сервер или там WebDAV
Преимущество облачного бекапа в данной ситуации по сравнению с Flickr'ом в том что если допустим случаться даже что-то вроде «7 дней в июне» (если не читана книга — там в России все более нормально но кроме всего прочего — тотальный обрыв интернет-каналов за пределы СНГ, не восстановимо никак и до данных тоже не добраться никак) а у нас был Synology C2… мы потеряли только бекап. Настраиваемый новый бекап на Selectel'овское облако с S3. Пока данные заливаются — сидим без облачного бекапа.
Либо можно взять какой-нибудь дистрибутив для nas — openmediavault, freenas, nas4free. Инструкции по установке ищутся по названию в гугле.
Если же речь про мастер-копию (DSM от Synology поставить не на родное железо) то ответ, да, можно. Проект Xpenology. Часть функционала использовать не получится нормально (например заливку фоток прямо по идентификатору устройства (с проходом NAT) а не dns-имени(на что публичный IP надо ж или проброс портов). С обновлениями проблемы… могут быть. Легальность вопрос скажем так — отдельный, Synology это не особо нравится (были случаи когда в новых версиях они ставили сюрпризы для тех кто так запускает — просто диски не монтируются) но проект вполне себе живет.
Но опять же — есть freenas и все такое если нужно совсем чистое решение на своем железе.
OneDrive 2500 в год стоит за терабайт. Смешная цена, если фотки действительно хочется сохранить. Четвертый год полет нормальный.
(и надежнее, с учетом таких вот сюрпризов) купить ту же Synology в двухдисковом варианте и настроить
Кража, пожар, всплеск электричества.
По уму:
нужно 2 устройства в разных помещениях, удаленных от друг друга.
А еще нужно настроить синхронизацию между ними.
А еще следить за выходом из строя и починять в случае чего
А еще забывают, что время того, кто это замутит, не бесплатно
Вы действительно считаете, что это будет обходиться дешевле 50 долларов в год?
Потому что каждая условно-нужная херня хочет не разово N денег. Она хочет постоянно шарить у вас в кармане, периодически вынуждая изучать очередную "обновленную политику"
Есть готовые решения на любой вкус и кошелек от различный производителей, а можно собрать на базе простенького компа и поставить Nextcloud, Seafile или что-то подобное.
50 Баксов в год за облако из которого тырят контент? Которое может закрыться или изменить правила игры? У которого, по-сути, в соглашении прописан отказ от ответственности? При том что за 400-500 баксов и пару вечеров можно сделать свое, скажем, на 6 терабайт?
Установил на него Server 2012, сделал RAID с помощью StableBit DrivePool из 3 1 ТБ WD Green и 1 3 ТБ Seagate SkyHawk. Грины у меня были, SkyHawk я купил просто в самом дешевом магазине по каталогу… Избыточность сделал только на папку с фотографиями, и в нее идет автобекап с такой же папки на рабочей машине.
Еще он крутит EMBY, кстати отличный сервер, отсылает кино на пару старых SMART ТВ и Chromecast, которое грузит самый обычный QBittorent, слушающий папку.
Плюс на микротике я сделал VPN, в котором видно только микросервер, и захожу на сервер не из дому с ноута или телефона, если очень нужно. IP статический.
Конечно, вариант эгоистический. Google Drive мне нравится редактором документов, а через FEX можно переслать много данных недорого. Но чисто под себя, не вижу смысла платить $$$ за облако, учесть, как все быстро меняется. Хранить бекапы (ну как у меня, за 1,5+ ТБ 199х-сегодня) в коммерческих облаках, черт возьми, дорого!
Мне тоже нравился Фликр, я раньше туда регулярно постил фото, добавлял в группы, обрабатывал отдельно для него… Эх.
Меня такое решение вполне устраивает по цене, храню у них два терабайта бэкапов, скоро на третий терабайт переползу.
Надо только приучить себя к мысли о том, что всё, загруженное в интернет, может стать достоянием публики и действовать соответственно. У себя я пришел к выводу, что от того, что 99% (по объёму) моей сохраняемой информации если выложить открыто, то мне от этого ничего не будет. Правда, это не повод её выкладывать. :)
А оставшийся один процент вполне можно шифровать перед загрузкой.
Если мне не изменяет память, то данные, которые грузятся на Ледник амазона предварительно шифруются.
Если говорить про Backblaze, то там тоже можно шифровать бэкап — 50 баксов в год и полный безлимит для одного устройства.
Так что можно бэкапиться и не бояться, что кто-то увидит данные
А про Backblaze — мне не нужны безлимит и одно устройство. Плюс мне домашний комп бэкапить не сильно нужно, в безлимит имело бы смысл домашний сервер загнать. Но на нём у меня windows server стоит, сомневаюсь, что персональный тарифный план это дело поддержит. Да и у них вроде как ограничения на сетевые диски, симлинки и т.п. Наверное, можно попробовать обойти это дело через виртуальную машину, но мне лень. Когда исчерпаются терабайты в вандрайве — тогда и буду думать. Но это ещё не скоро (если видео снимать не начну).
Если мне не изменяет память, то данные, которые грузятся на Ледник амазона предварительно шифруются.
Если говорить про Backblaze, то там тоже можно шифровать бэкап — 50 баксов в год и полный безлимит для одного устройства.
Если шифруешь сам, до загрузки, до передачи сторонним сервисам — да.
И сразу второй вопрос: как это всё выкачать? Хотя бы локально. Видимо, придётся писать своё решение (если только они API ещё заодно не порезали).
Хоть бы с ними такого не случилось, отличный сервис.
Там безлим на фотки «хорошего качества», т.е. до 12мпкс включительно. Если фотки больше 12 мегапикселей, то их сжимают, или доплачивайте.
бесплатно
Высокое качество
— Можно хранить неограниченное количество файлов.
— Фотографии сжимаются для экономии места. Если разрешение фото превышает 16 Мпикс., оно будет уменьшено до этого значения.
— Этого достаточно, чтобы напечатать фото размером 61x40,6 см.
— Если разрешение видео превышает 1080p, оно будет уменьшено до этого значения. Если разрешение видео не превышает 1080p, сохраненный файл по качеству не будет уступать оригиналу. Может быть утеряна некоторая информация, например субтитры.
платно
Исходное качество
— Размер свободного пространства ограничен. Файлы занимают место в аккаунте Google. — Проверьте доступный вам объем хранилища. Если свободное место закончилось, можно приобрести дополнительное пространство.
— Все фотографии и видео хранятся с тем же разрешением, в котором были сняты.
— Рекомендуется для фотографий с разрешением больше 16 Мпикс. и видео с разрешением больше 1080p.
— Рекомендуется для широкоформатной печати.
У Google photos есть прикол в том что хоть они и не будут удалять ваши фото если перестанете платить, они просто заблокируют Drive и Gmail(с невозможностью получать новые письма, иногда на неограниченный срок) с этого же аккаунта, и не разблокируют пока не заплатите хоть один раз даже если место в Drive освободите ниже лимита. Возможно просто старый баг, но всё равно не приятно.
И в высоком качестве фото все равно сжимаются, сравните размер фото до загрузки в облако и после.
support.google.com/photos/answer/6220791
Всегда рекомендую его владельцам iOS, страдающим от нехватки места в бесплатном icloud. Приложение Google Photos заливает все фотки себе и удаляет их с устройства.
Жаль только нет нормального плагина для adobe lightroom.
По результатам собственных тестов НЕ рекомендую Google Photos владельцам iOS:
- Стирается инфо о камере из видео
- Изменения в отредактированных видео и live photo игнорируются
- Самовольно собирает обратно разобранные серии (т.е. на телефоне фото отдельно, а в гугле становятся серией)
- Обратная ситуация — восстанавливает на телефон серии в виде отдельных фото
- Не читает локацию из не-apple GPS-тегов (это бывает после редактирования тегов в каком-нибудь приложении). При этом родные Photos из iOS локацию видят
- Портит время съёмки через некоторое время после заливки (не всегда, зависимость не уловил)
- Рандомно не синхронизирует некоторые фото, приходтся вручную дозаливать. Причём даже из одной серии часть фото может залиться, а часть нет
- Самовольно "стабилизирует" и обрезает Live Photos
А вот ещё случай из октября, это уже не относится к iOS, делал в веб-морде. Мои действия по порядку:
- Удалил все фото из альбома с 620 фото. Предварительно проверил, что корзина пустая.
- В корзину попало 530. Вернулся в альбом, а там осталось еще 171 фото (я же только что все их удалил?). Ах да, 530 + 171 равно ни разу не 620.
- Восстановил все фото из корзины. Теперь в альбоме 454 фото.
После этого всего моё доверие к гуглу сильно упало. Для хранения фото его больше не собираюсь использовать, плачу за iCloud.
Всегда опасаюсь что Apple удалит не то, что надо, стараюсь не использовать iCloud для фото в принципе
Я сейчас храню фотки одновременно на диске Яндекса, диске Гугла и на домашнем компьютере. Это не очень секьюрно, но как минимум в такой связке достаточно сложно что-либо потерять. Сложнее чем иметь отдельный VPS, NAT или любой другой сервис по отдельности.
Но мне конкретно это не принципиально — мне важно чтобы сохранились фотографии с минимальной финансовой подпиткой и минимальными телодвижениями. В таком формате такое хранение данных идеально выполняет свою задачу.
А вы как храните фотографии? Пару VPS с большими дисками?
Оттуда они бэкапятся на домашний сервер, в облако и, ручками, на внешний диск. Это если именно про хранение и бэкапы.
Фликр же, по большому счёту, не для этого предназначен был — народ туда хранить пошел только из-за халявного терабайта. А хозяева (дояхувые и нынешние) сайт видели как место для «фотовыставок» и общения пользователей между собой.
Если устройство с фотками не умеет синхронизироваться — то можно загрузить прямо в папку на компе.
Я не знаю что может быть проще. Моего участия вообще не требуется.
Бэкап папки /var/www это совершенно элементарная и очевидная вещь
Не знаю как для вас, но для меня перемещение с сервера на сервер 100 гб фоток это и не очень элементарно и не очень дешево. Как минимум сложнее, чем натравить автосинхронизатор какого-нибудь Гугла на папку с фотками
анлимит места
Откуда анлимит? Места столько, сколько есть на своем сервере. Никакой защиты от физического повреждения, отключения дома энергии, повреждения дисков (кроме RAID) или другой бытовой угрозы, а по деньгам даже учитывая бесплатную сейчас систему нужно вложиться в сервер, диски, энергообеспечение и бэкапирование, что при одинаковой надёжности будет стоить значительно дороже любого другого обсуждаемого тут решения. И стоимость будет значительно повышаться при повышении объема хранилища.
Зато секьюрно, да.
Но домашнего сервера с диском на 20 терабайт это не отменяет. :)
Толпе менеджеров нужно как-то получать повышение и показывать акционерам более лучшие результаты, чем прошлые менеджеры. Всегда и везде одно и то же
2. Похоже прогнозы Збигнева Бжезинского сбываются.
внешний локус контроля такой внешний-десу
А кто виноват тут, если не менеджеры?
Ничего не напоминает?
Тут дело не в халяве, а в том что правила игры меняют очень часто из одной крайности в другую.
И аналогия с благотворительностью не совсем верна. Получающие халявный хлеб пользователи ничего не теряют, если им перестанут раздавать хлеб. Пользователи Фликра в этой же ситуации могут потерять очень-очень ценные вещи — фото-архивы. Просто потому что менеджеров шатает.
Я бы провел аналогию с нашими пенсионными реформами за последние 25 лет.
Как «социальную сеть для фотографов» использую 500px.com — ограничение в 7 фото/неделя меня полностью устраивает, т.к. выбираюсь куда-нибудь по фотографировать я достаточно редко.
У меня лично припекает, что мои тщательно отобранные 1500 фото занимают 0.02% от терабайта. Но куплю про аккаунт, т.к. лучше фликра просто нет. Он и как инструмент хорош и удобен так и комьюнити там отличное. Если люди лишатся фликра, то это без сомнения и преувеличения будет культурная катастрофа.
Автор делает необоснованные выводы, что «шмуг» его прикончит.
Просто на свете нет ничего вечного. Умные люди, например, знают, что вопрос отказа жёсткого диска — это не «если», а «когда». Поэтому они бэкапят данные. Хотя бы на другой диск. Копирование с диска на диск — операция простая, давно отработанная, и доступная во всех операционных системах и между ними.
«Отказ» облачного провайдера — тоже всего лишь вопрос «когда». Он может выразиться во внезапной смене услуг и расценок (как с Фликром), потере аккаунта (см. «Mat Honen Apple hack»), и просто в багах. Поэтому кажется разумным иметь запасную копию облачных данных. Но… тут коса находит на камень.
Ибо копирование между большинством сервисов в лучшем случае — сложно и болезненно. В худшем же намеренно саботируется самими производителями, по понятным коммерческим причинам. И даже простая выкачка всего залитого обратно на диск — уже зачастую нетривиальна.
Вот и остаётся пока одно: master repository — дома, в облаке же — в лучшем случае запасная копия, которую не жалко и потерять.
Облака переживут и землятрясение и наводнение и пожар, но… утерянный пароль или смена бизнес-стратегии провайдера — и все ваши данные «приказали долго жить».
Локальный NAS никогда от вас не сбежит, но… в случае пожара или наводнения — вы, скорее всего, останетесь ни с чем.
Так что ни то, ни другое — не панацея.
Так вот, я полагаю, что главная копия должна быть именно домашней. Потому что если наоборот, то все инструменты по работе с данными, открыватели разных форматов и т.п. быстро останутся только в облаке, сделав мою домашнюю копию мёртвым бесполезным грузом. И, таким образом, вновь оставив меня без бэкапа.
В какую сторону идёт синхронизация при изменениях?
По дате последнего изменения? Поработали локально — новый файл уехал в облако, поработали в облаке — изменения приехали в локальную копию.
На практике, во-вторых, требует нетривильной работы для разрешения конфликтов. Вот, допустим, у нас в папке 1000 файлов. Мы поменяли разом 400 из них «там». Синхронизация ещё не закончилась, а мы поменяли разом 700 из них «здесь». Какое состояние должно победить? А если файлы указывают друг на друга, образуя сложную структуру? Вообще труба.
Но это хотя бы в принципе решается. В-главных же и увы, облачные провайдеры и одностороннюю-то синхронизацию на диск поддерживают хорошо если через одного и пень-колоду. Что возвращает нас к исходной проблеме.
Но у персонального пользователя описанные вами ситуации маловероятны, чтобы 400 файлов там, а потом сразу 700 файлов тут. Обычно работа идёт либо там, либо тут.
Впрочем, я, кажется, понимаю, что Вы хотите сказать. Что для Вас лично риск конфликтов представляется достаточно малым, и Вы согласны с ним жить. Это вполне допустимый подход.
Но главная-то проблема не в конфликтах, а в том, что ни один из провайдеров (насколько я в курсе) подобную двустороннюю синхронизацию всё равно не обеспечивает. Да половина не обеспечивают даже более простую выкачку данных на диск.
Что как бы делает наш дальнейший спор действительно бредовым.
Фотограф. У него две утилиты. Одна подписывает картинки в уголочке. Вторая — разворачивает правильно (что стало актуально, ибо 10-ка истинную ориентацию файла скрывает).
Запустили первую на системе А. 300 файлов, обрабатываются. Началась синхронизация. Открыли на системе Б, которая 7-ка. Ох, а часть файлов-то «на боку». (Дальшейшее не случилось, ибо у меня один мастер. Но случилось бы, будь их два). В спешке запускаем вторую утилиту, которая файлы разворачивает. Пошла синхронизация назад. Итог: часть файлов сначала развёрнута, потом подписана. Другая часть подписана, потом развёрнута. Изменения, замечу, необратимы — подпись из неправильного места убрать уже нельзя.
Более простой сценарий. Всего три файла. html-странички. Ссылаются друг на друга: A -> B -> C.
Решили, что последняя ссылка не нужна. Поменяли на A -> B, C. Синхронизация по какой-то причине задержалась (медленная сетка, демон лёг). На другой день решили, что правильно A, B -> C. Поменяли. Тут синхронизация нас догнала и получилось A, B, C. Вообще без ссылок. И осталось так на 10 лет, пока случайно не заметили. И сидим теперь, чешем репу: а как оно вообще должно было быть?
Ну и как уже сказал — у большинства облачных синхронизаторов вы в этом случае два файла получите.
На счет необратимости — а что, вы версионностью не пользуетесь?
Хотелось бы жить в мире, где пользователи никогда не ошибаются. Где сетка никогда не ложится и не тормозит. Где сервисы и демоны всегда крутятся. Где часы не расходятся между системами (привет, кстати, методу разрешения «по последней дате записи» от этого эффекта). В таком мире конфликты, наверное, действительно невозможны. Правда, я подозреваю, в нём и бэкапы не нужны будут :))
Но мы живём в мире реальном, и в любой распределённой системе эти эффекты приходится учитывать (вот, кстати, неплохой учебник, там целая глава посвящена методам разрешения конфликтов: www.amazon.com/Designing-Data-Intensive-Applications-Reliable-Maintainable/dp/1449373321). И, увы, способ «по последней записи» работает далеко не всегда. Скажем, он не вылечит ситуацию с тремя hmtl-файлами. Где пользовательской ошибки, кстати, не было.
Но мы всё не о том. Я не спорю, что правильная система с multi-leader replication в принципе возможна. И что она может разрешать конфликты, хотя и не столь простыми методами, как Вы предлагаете.
Проблема в другом. Насколько я в курсе, большинство сервисов двустороннюю синхронизацию в принципе не поддерживают, превращая всю нашу дискуссию в чисто теоретический дебат.
На практике, кто поддерживает двустороннюю синхронизацию? Это не риторический вопрос. Если такие есть, я, может, сам бы воспользовался.
ИМХО, у любого, кто заботится о сохранности данных, должно быть жёсткое табу на необратимые модификации фотографий :)
У меня в личном архиве фотки, где-то, с 2002-го года. Ни одна из них не менялась деструктивно :)
Одна из причин, по которым я Гуглу не могу простить смерть Пикасы. Вменяемой мультиплатформенной альтернативы без привязок к БД с неразрушающими изменениями и с сохранением всех результатов в файловой системе больше нет в природе. Заменить Пикасу под такой юзкейс вообще нечем. Пользуюсь старыми уже не поддерживаемыми версиями с неработающим онлайн-функционалом и с ужасом жду времён, когда оно перестанет работать :)
Но когда копий две, всегда возникает вопрос: какая из них основная (master), а какая — лишь отражение (slave)?Откуда взялись две копии? Их три должно быть. Одна у вас на компьютере (она же мастер), вторая — на полке, третья — в облаке.
У меня многие фотки хранятся в 5-7 репозиториях. Основной домашний архив, бэкап на домашнем сервере, бэкап в облаке, ноутбук, рабочий десктоп дома, рабочий десктоп на работе…
Проблем с конфликтами нет, учитывая, что syncthing, которым я пользуюсь, мало того, что имеет версионный бэкап, так ещё в случае конфликтов хранит оба конфликтующих варианта. Случаи бывают не часты, так что разрулить можно и вручную :)
Общий объём фотоархива около 812Гб. Но в полном объёме он только на 3-4 машинах. Описанное выше обычно касается архивов за последние год-два-три, это по 60-80Гб за год.
И вот тогда я принял решение срочно их покинуть. Выкачать через браузер или через приложение всё, что там было, оказалось просто нереальным. И тогда мне пришлось написать приложение, которое эмулировало браузер при запросах (пришлось вручную выковырять временный токен при реальной работе через браузер), и выкачать свой архив таким способом. Увы, пользователи, у которых нет моих навыков, оказались в проигрышном положении. При этом я напоминаю, это был платный аккаунт, с казалось бы, понятными правилами игры…
Перешел на pCloud с их 2 TB на lifetime подписку (тогда она стоила дешевле — 250 EUR). У них, хоть и кривенькое, но вполне рабочее API, под которое я адаптировал свой плагин для Far Manager (ранее заточенный под Amazon Cloud Drive). И пока что всё работает, как надо. Правда, я не питаю иллюзий, что так будет вечно (ибо lifetime это на самом деле либо до конца моей жизни, либо до конца жизни сервиса, и не факт, что я проживу меньше), поэтому держу и локальную копию всего, что заливаю на pCloud.
С нынешним «нововведением» я просто удалил те фотографии, на которые точно знал, что на них ниоткуда ссылок нет (моих, по крайней мере). В итоге осталось 992 фотографии (из 20 тысяч).
Ну и само ограничение по количеству — глупое. Ну нет у вас возможности терабайт всем подряд выдавать — так оставьте по гигабайту. Большинству (кто не хранит на сайте оригиналы) этого вполне хватило бы на всю коллекцию.
С другой стороны — 50 баксов в год это всё же не 400 (или запрет вставлять фото), как у фотобакета в своё время. Да и объявили за три месяца, а не через два дня после нововведений.
Единственное, что мне всерьёз не нравится — это то, что лишнее будет удаляться. Потому сам всё и грохнул, чтобы роботы не напортачили.
Знаю, что ещё imgur умеет такое делать, но там интерфейс ещё более стрёмный, да и лимит на 50 фоток в час с одного IP иногда всё портит.
Правильно ли я понимаю, что ни гугл, ни яндекс, ни майкрософт в своих облаках такие ссылки генерить не умеют?
Если кто-нибудь подскажет ещё хороший сервис с такой фичей, был бы очень благодарен.
Сколько их таких было… Год за годом подтверждается утверждение, что централизованным сервисам в отношении долговременного хранения данных верить нельзя. Никогда. Что бы они не обещали и какая бы у них не была до этого репутация. Сменятся в очередной раз менеджеры и очередные труды юзеров превращаются в тыкву.
Рекомендуемым тут селфхостам тоже верить нельзя. Мало кто озаботится бэкапами. Пропадёт интерес. Наконец, человека не станет — и всё, ничего не останется. У меня так несколько раз наследие почивших знакомых пропадало… Жизнеспособность таких решений ещё ниже, чем централизованных.
С распределёнными решениями всё сложнее. Да, очень интересно выглядят таковые, например, на #ActivePub. Тот же #Mastodon, если в роли микроблогов, но фотки с тегами можно и там размещать. Активно пилится и «вот-вот почти работает» #PixelFed — это уже полноценный фотохостинг. Но с ними практически та же беда. Сеть в целом при проблемах конкретных узлов будет работать как ни в чём ни бывало. Но вот пользователям таких нод ничуть не легче. Упал твой сервер — всё, как ни в чём ни бывало ты продолжить работать не сможешь. И ссылки снова становятся тыквами.
Идеальным решением тут были бы полностью децентрализованные решения, типа моей любимицы, #ZeroNet. Но и там есть свои косяки. На публикацию в ZN нельзя дать гарантированно долгоживущую ссылку из в обычном Интернет. Да, есть публичные ZN-прокси (гейты), через которых можно получить доступ к контенту ZN, в том числе по прямым ссылкам. Но они, как правило, недолговечны, их легко блокируют из-за того, что наряду с легитимным контентом они предоставляют доступ и к противозаконному. Ссылки после этого при ручной замене хоста на другой будут жизнеспособны, но это требует активного действия читателя, это сегодня для большинства сложно и не нужно. Другая проблема — в ZN сегодня нет качественных фотохостингов. Есть собственные блоги — фотографии можно размещать там. Но не это не нормальные фотогалереи. Есть пара ранних реализаций фотогалерей, но они кривые и глючные… Для себя я, всё же, выбрал в качестве базы для долговременного хранения публикации в блогах ZeroNet, «бессрочность» хранения и независимость от сторонних людей подкупает. Но ссылки на свои материалы я даю через свой же прокси, и когда он накроется, то хотя материалы в ZN будут доступны, ссылки в обычном Интернете пропадут…
Словом, идеала нет. Но твёрдо ясно одно: централизованные ресурсы в отношении долговременного хранения — это худшее из плохого :)
Решить это можно лишь разной степени избыточностью( больше дублирование — больше надёжность, больше издержки и меньше желание пользователей тащить этот груз на себе. Меньше — меньше надёжность, вплоть до необратимой потери данных при поломке единственного харда на чьём-то старом ноуте, на котором хранился конкретный файл, но меньше издержки ).
Либо, как в самом примитивном случае, у каждого хранится полная копия всего хранилища.
Что, в любом из вариантов, выглядит довольно нелепо для такой тяжёлой штуки, как медиа.
Худшее из плохого — это хранение ценных данных не в каком-то центральном хранилище( что заранее предупредит о проблемах )
Вот у тебя есть проблема. Попробуй теперь скачать терабайт фоток с Flickr :) Учитывая, что адекватных инструментов для этого нет. А какая была эпопея по скачиванию нескольких терабайт с Амазона, когда они внезапно заявили о прекращении халявы. Говорить о том, что это меньшая проблема, может только тот, кто не наступал на эти грабли :D
а вообще неизвестно где и как, при полной неизвестности, когда у кого-то что-то там откажет/сломается.
Если ты видишь, что твои данные доступны хотя бы у 5-6 пиров, это уже офигенная гарантия. А если они у 50 пиров? :)
Что, в любом из вариантов, выглядит довольно нелепо для такой тяжёлой штуки, как медиа
Тут важно сразу разделить понятия хранения абстрактных приватных данных и хранения тех же фоток в социальных целях. При чём в последнем случае ещё надо делить блоги и фотоальбомы, поскольку подходы и аудитории разные по сути.
Распределённые сети сегодня почти не решают вопросы приватных данных. Sia или Storj не взлетают, да и не взлетят, наверное. Потому что обычному пользователю не интересно хранить чужие закрытые бессмысленные для него данные. Даже если кто-то в обмен хранит его файлы. Но этот вопрос не решается никем и тут, действительно, придётся платить.
А вот что касается социальных решений, о которых пошла речь и к которым относится мой комментарий, вот тут в распределённых сетях всё намного лучше. И оправданней с точки зрения пользователей. То, что интересно сообществу, будет храниться гарантированно и столь долго, сколько будет оставаться интерес, хоть у кого-то из участников. Заодно получается автоматическая очистка инфопространства от никому не нужного мусора.
Пользовательские данные обладают бесконечной ценностью. Если сервис относится к данным иначе, а вы продолжаете им пользоваться вы обречены наступать на грабли снова и снова
Критикуешь, предлагай варианты решения.
Без предложений выхода из пике статья какая-то неполная…
Хорошо, что есть комментарии.
Плохо, что «эффективные менеджеры» из не прочтут.
Критикуешь, предлагай варианты решения.
Без предложений выхода из пике статья какая-то неполная…
Это замечание было бы уместно на совете директоров Фликра, но в публицистике на хабре на кой ляд нужны советы постороннего человека относительно того, как реорганизовать какую-то заморскую компанию? Причем советы, предназначенные людям, которые, во-первых, имеют совершенно другой набор исходных данных, во-вторых, никак и никогда эти советы не увидят.
В какой-то мере заменой Фликру были Яндекс Фотки, но теперь и там полный швах, сервис переезжает на Яндекс Диск.
И это самая серьёзная проблема?! * смех сквозь слёзы *
Если вы не в курсе, то Яндекс сейчас отжимают вслед за ВКонтактником!
Как «эффективные менеджеры» утопили Flickr