Я бы с большим интересом ознакомился с какой-нибудь серьёзной работой, где это аккуратно измеряется. Всё, что мне удалось найти — это не очень внятные научно-популярные сайты. Где не проводится разницы между «тащить волоком» или «поднять», равно как «один раз в рывке» или «регулярно каждый день». А контроль этих параметров легко десятку раз дать может. По этой причине я не стал включать насекомых в анализ. Хотя и был соблазн.
Сам я, наблюдая за муравьями (могу видео поделиться), видел, что поднимают они соломинки размером примерно с себя, то есть и весом где-то такие же.
Но, как сказано, если есть работы, было бы интересно их изучить.
Всё верно. Но, скажем так, у меня есть основания полагать, что в ближайшие годы перед линуксом встанет интересный выбор. Либо быть поглощённым большими корпорациями, с (почти) полной потерей девелоперской вольницы. Либо стать системой с существенным десктопным присутствием и большим количеством юзеров. Пусть даже не самых продвинутых юзеров, с не всегда умными «хотелками». Собственно, экосистема этих юзеров и есть гарантия от поглощения. Я, конечно, могу ошибаться, и, к сожалению, не могу поделиться всеми основаниями своего мнения, так что будем его считать просто персональным взглядом на вещи. Но мне бы хотелось, чтобы линукс выжил и остался более-менее независимым. Что и сподвигло меня на исходный комментарий.
Разумеется, команда линукса имеет право фокусироваться на чём хочет. Но я не вижу, как она получит много пользователей, не желая слушать про их «хотелки».
Я — человек, пользовавшийся Линуксом в прошлом тысячелетии. И недавно решивший вернуться к нему. Поставил дома Убунту, пользуюсь ею параллельно с Виндой. И вот каким опытом я поделюсь.
У меня уже есть привычная операционная система: Винда. На ней лежат мои файлы, стоят приложения, в её настройку инвестировано немало сил и времени. Я не просто не хочу — я не могу бросить всё это и разом перескочить на Линукс. Поэтому я вынужден гонять его параллельно с парком Виндовых машин, постепенно перенося функциональность с одной платформы на другую.
Вот эта параллельная, «прорастающая» встраиваимость и должна быть ключом Линукса к расширению базы пользователей. Но сегодня с ней трудно.
Простейший сценарий: доступ к виндовым файлам через SMB. У меня ж там терабайты архивов. Неделю заняло, чтобы понять и настроить. Опытные линуксоиды будут смеяться, возможно. Но поверьте, даже у неглупого человека уходит неделя на понимание процесса и разбор всех багов и особенностей, если делать это впервые после 20-летнего перерыва. Почему бы не сфокусироваться и не сделать этот сценарий рабочим сразу от загрузки системы? Людям критичен доступ к их архивам. Даже если он происходит по «такому плохому» SMB, менее трудоёмкой альтернативы всё равно нет.
Удалённый доступ к системе. Сначала пытался настроить через виндовый RPD. Есть поделки, поддерживающие это. Сделал за день, но русский язык не работает. Читал интернет неделю, пока не увидел, что да, есть такой баг, непочинен. Переделал через X2Go, вроде работает. Почему бы такой базовый сценарий тоже сразу не встроить? Скажем, как птичку в момент установки?
Вот из таких мелочей и состоит теперь мой переезд. Я верю в Линукс и всё равно намерен углублять его использование. Но, думаю, его команде полезно было бы сфокусироваться не только на новых пользователях, начинающих компьютерную жизнь с нуля, а на возможности удобного, беспроблемного «параллельного» использования Линукса людьми, уже вложившимися в виндовую инфраструктуру.
Надеюсь, мой комментарий никого не обидел. Спасибо за внимание!
В целом да. Но — если гонять на домашней машине несколько виртуалок, то многоядерность становится критичной. Отдаёшь каждой машине по два процессора и по отдельному диску — и всё живёт, не спотыкаясь друг о друга. Я лично уже лет 7 почти только из-под виртуалок и работаю. Возможность сохранять произвольные состояния и откатывать их обратно в любой момент очень завлекает.
Проблема печальная. Но я думаю, что это лишь верхушка айсберга.
20 лет назад, чтобы программа получила жизнь, требовались три вещи:
1. Написавший её девелопер
2. Заинтересованный покупатель
3. (Опционально) посредник, чтобы помочь первому найти второго
Сейчас на всех крупных платформах требуется Четвёртый: Некто, Кто Разрешает. Сам Четвёртый ничего не производит и, нередко, не разбирается ни в программировании, ни в потребностях покупателя. Он лишь плотно прижимает печать. Впрочем, на практике 95% его работы вообще автоматизировано через всякие сканеры, так что управляет Четвёртый чаще не конкретными решениями по конкретным приложениям, а общей политикой. Какие правила вносить в требования, каков % допустимой ошибки, через сколько часов давать ответ и т.п.
Говоря честно, польза от Четвёртого всё-таки есть. Совсем уж откровенные зловреды и обманки он не пропустит.
Но он так же не пропустит любую программу, которая не удовлетворяет правилам компании — даже если покупатель эту программу хочет! Я вот думаю: смог ли бы DOOM увидеть свет, если бы ему пришлось распространяться через Google Play или прочий App Store? Кровищи-то там вполне хватает. Что если бы это не понравилось Четвёртому?
Компании, в небезуспешной попытке победить вредоносное ПО, похоже, попутно убивают ещё одну вещь: способность программерской среды генерить принципиально новые идеи и программы. И если это действительно так, то лет через 20 это им (и нам всем) ещё очень аукнется.
Разумеется, в первом случае имеет место ошибка пользователя. Но мы дрессируем пользователя никогда не ошибаться, или пишем систему, устойчивую хотя бы к типовым ошибкам?
Хотелось бы жить в мире, где пользователи никогда не ошибаются. Где сетка никогда не ложится и не тормозит. Где сервисы и демоны всегда крутятся. Где часы не расходятся между системами (привет, кстати, методу разрешения «по последней дате записи» от этого эффекта). В таком мире конфликты, наверное, действительно невозможны. Правда, я подозреваю, в нём и бэкапы не нужны будут :))
Но мы живём в мире реальном, и в любой распределённой системе эти эффекты приходится учитывать (вот, кстати, неплохой учебник, там целая глава посвящена методам разрешения конфликтов: www.amazon.com/Designing-Data-Intensive-Applications-Reliable-Maintainable/dp/1449373321). И, увы, способ «по последней записи» работает далеко не всегда. Скажем, он не вылечит ситуацию с тремя hmtl-файлами. Где пользовательской ошибки, кстати, не было.
Но мы всё не о том. Я не спорю, что правильная система с multi-leader replication в принципе возможна. И что она может разрешать конфликты, хотя и не столь простыми методами, как Вы предлагаете.
Проблема в другом. Насколько я в курсе, большинство сервисов двустороннюю синхронизацию в принципе не поддерживают, превращая всю нашу дискуссию в чисто теоретический дебат.
На практике, кто поддерживает двустороннюю синхронизацию? Это не риторический вопрос. Если такие есть, я, может, сам бы воспользовался.
Предотвращение, а не разрешение. Утилита локает всю папку от записи, и не отдаёт, пока не закончит или не умрёт. Таким образом, проблема просто не возникает.
Легко. Сам чуть не налетел буквально неделю назад.
Фотограф. У него две утилиты. Одна подписывает картинки в уголочке. Вторая — разворачивает правильно (что стало актуально, ибо 10-ка истинную ориентацию файла скрывает).
Запустили первую на системе А. 300 файлов, обрабатываются. Началась синхронизация. Открыли на системе Б, которая 7-ка. Ох, а часть файлов-то «на боку». (Дальшейшее не случилось, ибо у меня один мастер. Но случилось бы, будь их два). В спешке запускаем вторую утилиту, которая файлы разворачивает. Пошла синхронизация назад. Итог: часть файлов сначала развёрнута, потом подписана. Другая часть подписана, потом развёрнута. Изменения, замечу, необратимы — подпись из неправильного места убрать уже нельзя.
Более простой сценарий. Всего три файла. html-странички. Ссылаются друг на друга: A -> B -> C.
Решили, что последняя ссылка не нужна. Поменяли на A -> B, C. Синхронизация по какой-то причине задержалась (медленная сетка, демон лёг). На другой день решили, что правильно A, B -> C. Поменяли. Тут синхронизация нас догнала и получилось A, B, C. Вообще без ссылок. И осталось так на 10 лет, пока случайно не заметили. И сидим теперь, чешем репу: а как оно вообще должно было быть?
Вы не видите, но на разрешении конфликтов при репликации целая индустрия построена. Конфликты тем и опасны, что случаются редко, обнаруживаются иногда лишь через годы, а разрешаются крайне дорого. Этакие незаметные мины.
Впрочем, я, кажется, понимаю, что Вы хотите сказать. Что для Вас лично риск конфликтов представляется достаточно малым, и Вы согласны с ним жить. Это вполне допустимый подход.
Но главная-то проблема не в конфликтах, а в том, что ни один из провайдеров (насколько я в курсе) подобную двустороннюю синхронизацию всё равно не обеспечивает. Да половина не обеспечивают даже более простую выкачку данных на диск.
Что как бы делает наш дальнейший спор действительно бредовым.
Вы удивитесь, сколько файлов и как быстро иногда за раз меняются, когда работаешь с фотографиями :)) А когда нужно срочно что-то переделать для заказчика, вообще можно забыть, где работаешь.
Да, есть такая концепция. Multi-leader replication. В теории она прекрасно разрешает этот спор.
На практике, во-вторых, требует нетривильной работы для разрешения конфликтов. Вот, допустим, у нас в папке 1000 файлов. Мы поменяли разом 400 из них «там». Синхронизация ещё не закончилась, а мы поменяли разом 700 из них «здесь». Какое состояние должно победить? А если файлы указывают друг на друга, образуя сложную структуру? Вообще труба.
Но это хотя бы в принципе решается. В-главных же и увы, облачные провайдеры и одностороннюю-то синхронизацию на диск поддерживают хорошо если через одного и пень-колоду. Что возвращает нас к исходной проблеме.
Спор не совсем бредовый. Да, разумнее всего хранить данные и дома, и в облаке. Но когда копий две, всегда возникает вопрос: какая из них основная (master), а какая — лишь отражение (slave)? В какую сторону идёт синхронизация при изменениях?
Так вот, я полагаю, что главная копия должна быть именно домашней. Потому что если наоборот, то все инструменты по работе с данными, открыватели разных форматов и т.п. быстро останутся только в облаке, сделав мою домашнюю копию мёртвым бесполезным грузом. И, таким образом, вновь оставив меня без бэкапа.
Проблема, к сожалению, шире. Сегодня ни одно облачное решение не пригодно к хранению персональных данных. По крайней мере, в качестве основного, а не запасного хранилища. И дело вовсе не в безопасности или приватности.
Просто на свете нет ничего вечного. Умные люди, например, знают, что вопрос отказа жёсткого диска — это не «если», а «когда». Поэтому они бэкапят данные. Хотя бы на другой диск. Копирование с диска на диск — операция простая, давно отработанная, и доступная во всех операционных системах и между ними.
«Отказ» облачного провайдера — тоже всего лишь вопрос «когда». Он может выразиться во внезапной смене услуг и расценок (как с Фликром), потере аккаунта (см. «Mat Honen Apple hack»), и просто в багах. Поэтому кажется разумным иметь запасную копию облачных данных. Но… тут коса находит на камень.
Ибо копирование между большинством сервисов в лучшем случае — сложно и болезненно. В худшем же намеренно саботируется самими производителями, по понятным коммерческим причинам. И даже простая выкачка всего залитого обратно на диск — уже зачастую нетривиальна.
Вот и остаётся пока одно: master repository — дома, в облаке же — в лучшем случае запасная копия, которую не жалко и потерять.
Сам я, наблюдая за муравьями (могу видео поделиться), видел, что поднимают они соломинки размером примерно с себя, то есть и весом где-то такие же.
Но, как сказано, если есть работы, было бы интересно их изучить.
У меня уже есть привычная операционная система: Винда. На ней лежат мои файлы, стоят приложения, в её настройку инвестировано немало сил и времени. Я не просто не хочу — я не могу бросить всё это и разом перескочить на Линукс. Поэтому я вынужден гонять его параллельно с парком Виндовых машин, постепенно перенося функциональность с одной платформы на другую.
Вот эта параллельная, «прорастающая» встраиваимость и должна быть ключом Линукса к расширению базы пользователей. Но сегодня с ней трудно.
Простейший сценарий: доступ к виндовым файлам через SMB. У меня ж там терабайты архивов. Неделю заняло, чтобы понять и настроить. Опытные линуксоиды будут смеяться, возможно. Но поверьте, даже у неглупого человека уходит неделя на понимание процесса и разбор всех багов и особенностей, если делать это впервые после 20-летнего перерыва. Почему бы не сфокусироваться и не сделать этот сценарий рабочим сразу от загрузки системы? Людям критичен доступ к их архивам. Даже если он происходит по «такому плохому» SMB, менее трудоёмкой альтернативы всё равно нет.
Удалённый доступ к системе. Сначала пытался настроить через виндовый RPD. Есть поделки, поддерживающие это. Сделал за день, но русский язык не работает. Читал интернет неделю, пока не увидел, что да, есть такой баг, непочинен. Переделал через X2Go, вроде работает. Почему бы такой базовый сценарий тоже сразу не встроить? Скажем, как птичку в момент установки?
Вот из таких мелочей и состоит теперь мой переезд. Я верю в Линукс и всё равно намерен углублять его использование. Но, думаю, его команде полезно было бы сфокусироваться не только на новых пользователях, начинающих компьютерную жизнь с нуля, а на возможности удобного, беспроблемного «параллельного» использования Линукса людьми, уже вложившимися в виндовую инфраструктуру.
Надеюсь, мой комментарий никого не обидел. Спасибо за внимание!
20 лет назад, чтобы программа получила жизнь, требовались три вещи:
1. Написавший её девелопер
2. Заинтересованный покупатель
3. (Опционально) посредник, чтобы помочь первому найти второго
Сейчас на всех крупных платформах требуется Четвёртый: Некто, Кто Разрешает. Сам Четвёртый ничего не производит и, нередко, не разбирается ни в программировании, ни в потребностях покупателя. Он лишь плотно прижимает печать. Впрочем, на практике 95% его работы вообще автоматизировано через всякие сканеры, так что управляет Четвёртый чаще не конкретными решениями по конкретным приложениям, а общей политикой. Какие правила вносить в требования, каков % допустимой ошибки, через сколько часов давать ответ и т.п.
Говоря честно, польза от Четвёртого всё-таки есть. Совсем уж откровенные зловреды и обманки он не пропустит.
Но он так же не пропустит любую программу, которая не удовлетворяет правилам компании — даже если покупатель эту программу хочет! Я вот думаю: смог ли бы DOOM увидеть свет, если бы ему пришлось распространяться через Google Play или прочий App Store? Кровищи-то там вполне хватает. Что если бы это не понравилось Четвёртому?
Компании, в небезуспешной попытке победить вредоносное ПО, похоже, попутно убивают ещё одну вещь: способность программерской среды генерить принципиально новые идеи и программы. И если это действительно так, то лет через 20 это им (и нам всем) ещё очень аукнется.
Хотелось бы жить в мире, где пользователи никогда не ошибаются. Где сетка никогда не ложится и не тормозит. Где сервисы и демоны всегда крутятся. Где часы не расходятся между системами (привет, кстати, методу разрешения «по последней дате записи» от этого эффекта). В таком мире конфликты, наверное, действительно невозможны. Правда, я подозреваю, в нём и бэкапы не нужны будут :))
Но мы живём в мире реальном, и в любой распределённой системе эти эффекты приходится учитывать (вот, кстати, неплохой учебник, там целая глава посвящена методам разрешения конфликтов: www.amazon.com/Designing-Data-Intensive-Applications-Reliable-Maintainable/dp/1449373321). И, увы, способ «по последней записи» работает далеко не всегда. Скажем, он не вылечит ситуацию с тремя hmtl-файлами. Где пользовательской ошибки, кстати, не было.
Но мы всё не о том. Я не спорю, что правильная система с multi-leader replication в принципе возможна. И что она может разрешать конфликты, хотя и не столь простыми методами, как Вы предлагаете.
Проблема в другом. Насколько я в курсе, большинство сервисов двустороннюю синхронизацию в принципе не поддерживают, превращая всю нашу дискуссию в чисто теоретический дебат.
На практике, кто поддерживает двустороннюю синхронизацию? Это не риторический вопрос. Если такие есть, я, может, сам бы воспользовался.
Фотограф. У него две утилиты. Одна подписывает картинки в уголочке. Вторая — разворачивает правильно (что стало актуально, ибо 10-ка истинную ориентацию файла скрывает).
Запустили первую на системе А. 300 файлов, обрабатываются. Началась синхронизация. Открыли на системе Б, которая 7-ка. Ох, а часть файлов-то «на боку». (Дальшейшее не случилось, ибо у меня один мастер. Но случилось бы, будь их два). В спешке запускаем вторую утилиту, которая файлы разворачивает. Пошла синхронизация назад. Итог: часть файлов сначала развёрнута, потом подписана. Другая часть подписана, потом развёрнута. Изменения, замечу, необратимы — подпись из неправильного места убрать уже нельзя.
Более простой сценарий. Всего три файла. html-странички. Ссылаются друг на друга: A -> B -> C.
Решили, что последняя ссылка не нужна. Поменяли на A -> B, C. Синхронизация по какой-то причине задержалась (медленная сетка, демон лёг). На другой день решили, что правильно A, B -> C. Поменяли. Тут синхронизация нас догнала и получилось A, B, C. Вообще без ссылок. И осталось так на 10 лет, пока случайно не заметили. И сидим теперь, чешем репу: а как оно вообще должно было быть?
Впрочем, я, кажется, понимаю, что Вы хотите сказать. Что для Вас лично риск конфликтов представляется достаточно малым, и Вы согласны с ним жить. Это вполне допустимый подход.
Но главная-то проблема не в конфликтах, а в том, что ни один из провайдеров (насколько я в курсе) подобную двустороннюю синхронизацию всё равно не обеспечивает. Да половина не обеспечивают даже более простую выкачку данных на диск.
Что как бы делает наш дальнейший спор действительно бредовым.
На практике, во-вторых, требует нетривильной работы для разрешения конфликтов. Вот, допустим, у нас в папке 1000 файлов. Мы поменяли разом 400 из них «там». Синхронизация ещё не закончилась, а мы поменяли разом 700 из них «здесь». Какое состояние должно победить? А если файлы указывают друг на друга, образуя сложную структуру? Вообще труба.
Но это хотя бы в принципе решается. В-главных же и увы, облачные провайдеры и одностороннюю-то синхронизацию на диск поддерживают хорошо если через одного и пень-колоду. Что возвращает нас к исходной проблеме.
Так вот, я полагаю, что главная копия должна быть именно домашней. Потому что если наоборот, то все инструменты по работе с данными, открыватели разных форматов и т.п. быстро останутся только в облаке, сделав мою домашнюю копию мёртвым бесполезным грузом. И, таким образом, вновь оставив меня без бэкапа.
Просто на свете нет ничего вечного. Умные люди, например, знают, что вопрос отказа жёсткого диска — это не «если», а «когда». Поэтому они бэкапят данные. Хотя бы на другой диск. Копирование с диска на диск — операция простая, давно отработанная, и доступная во всех операционных системах и между ними.
«Отказ» облачного провайдера — тоже всего лишь вопрос «когда». Он может выразиться во внезапной смене услуг и расценок (как с Фликром), потере аккаунта (см. «Mat Honen Apple hack»), и просто в багах. Поэтому кажется разумным иметь запасную копию облачных данных. Но… тут коса находит на камень.
Ибо копирование между большинством сервисов в лучшем случае — сложно и болезненно. В худшем же намеренно саботируется самими производителями, по понятным коммерческим причинам. И даже простая выкачка всего залитого обратно на диск — уже зачастую нетривиальна.
Вот и остаётся пока одно: master repository — дома, в облаке же — в лучшем случае запасная копия, которую не жалко и потерять.