Comments 38
Может проще заставить всех писать портабельные приложения?
Тс, тише Вы, не всё ж сразу:)
А если серьёзно, то статья получилась более приложение-ориентированна, но на самом деле возможности шире (я попытался привести пример в секции «преимущества»)
А если серьёзно, то статья получилась более приложение-ориентированна, но на самом деле возможности шире (я попытался привести пример в секции «преимущества»)
Да не дай бог. «xcopy deployment» отличается от «portable» и очень существенно: портабл приложения таскают свои настройки с собой, а значит требуют прав на запись в собственный каталог.
Касательно применимости вашей идеи изолированности ОС и аппликаций: к windows-системам это малоприменимо ввиду сильной зависимости самих аппликаций от «полезных изменений в системе» (portable не в счет), которое зачастую заключается не столько в добавлении новых, сколько в изменении существующих системных файлов. Как это реализовать в предложенной вами модели ФС я не представляю.
Win в статье упоминается просто как родоначальник идеи. Статью специально включил в хаб *nix, а не Win, т.к. конечно же речь шла о ФС в *nix-подобных системах.
Если я обнаружу, что одно из моих приложений делает «полезные изменения в системе» (в том смысле, что приводите Вы — меняет существующие системные файлы), я не только его немедленно снесу, но и лет 5-10 не будут даже смотреть в сторону приложений данного производителя. Ибо быдлокод.
Ах да, полная изоляция (виртуализация) приложений тоже существует. У MS есть свое решение, но оно далеко не единственное. Из полезных сайдэффектов то, что большие приложения могут «стримиться» на машину, то есть получать файлы по мере необходимости.
А внутри этих пакетов будет всё равно древовидная структура файлов, насколько я понял
На время этого комментария «Какая глупость! (и я привёл в комментариях объяснение почему)» ответили 14 человек, а комментариев всего 2.
Внимание! Кто-то крадет комментарии!
Внимание! Кто-то крадет комментарии!
Не совсем ясно, зачем и как это делать на уровне файловой системы. Это делается на уровне ОС или даже стороннего ПО класса HIPS, создающего sandbox'ы под каждое приложение. Можно рассмотреть идею постоянных sandbox'ов, которые будут восстанавливаться при запуске приложения в предыдущем состоянии и т.д.
Прошу заметить что не смотря на то, что в тексте речь идёт о приложениях, спектр применения этой технологии гораздо шире, в том числе для приватных образов, которые монтируются только для конкретного пользователя, а так же образов файлов пользователя, которые он хотел бы контролировать и обособить от всей системы в целом (буквально в понедельник увольнялся и это и подтолкнуло написать статью, когда я чистил за собой систему. Хоть я и соблюдал основные правила, такие как «хранить всё в папке пользователя» и так далее, но некое волнение всё равно было)
Опять же — приватные образы легко делаются с помощью ПО (TrueCrypt, SafeDisk и т.д.).
Файловая система, в первую очередь, это способ организации хранения данных на физическом носителе. ФС не должна выполнять прикладные функции, ФС должна обеспечивать быстрый доступ к данным. Даже функции по резервному копированию и т.д. чаще всего реализованы не в ФС, а в прикладных утилитах к ним.
Файловая система, в первую очередь, это способ организации хранения данных на физическом носителе. ФС не должна выполнять прикладные функции, ФС должна обеспечивать быстрый доступ к данным. Даже функции по резервному копированию и т.д. чаще всего реализованы не в ФС, а в прикладных утилитах к ним.
Тут идея в том, что любой файл, записанный от пользователя user, будет писаться в образ этого user-а, автоматически. Без повышения привелегий он просто не сможет записать его куда-то ещё.
Ну как же. Многие современные ФС имеют всякие прикладные функции, например, разграничение прав доступа или сжатие и шифрование данных. Реализация базовых прикладных функций на уровне ФС позволяет сделать их достаточно надежными и производительными.
Не могу понять кто у кого идею стырил
www.opennet.ru/opennews/art.shtml?num=36043
«На данном этапе разработчики планируют использовать для распространения приложений формат „app image“, при котором вся файловая структура, необходимая для работы приложения, вместе с библиотеками упаковывается в образ файловой системы. После установки этот образ подключается к собственной точке монтирования, к которой подключаются все необходимые приложению компоненты ОС с применением изоляции с помощью пространств имен. В результате приложение оказывается в минималистичном Linux-контейнере.»
www.opennet.ru/opennews/art.shtml?num=36043
«На данном этапе разработчики планируют использовать для распространения приложений формат „app image“, при котором вся файловая структура, необходимая для работы приложения, вместе с библиотеками упаковывается в образ файловой системы. После установки этот образ подключается к собственной точке монтирования, к которой подключаются все необходимые приложению компоненты ОС с применением изоляции с помощью пространств имен. В результате приложение оказывается в минималистичном Linux-контейнере.»
Класс! При этом я могу найти свидетелей, которым свою идею я рассказывал года этак два назад:)
Но я действительно крайне рад тому, что ведутся работы в этом направлении:) Именно ради этого комментария считайте я статью и писал! Спасибо)
Но я действительно крайне рад тому, что ведутся работы в этом направлении:) Именно ради этого комментария считайте я статью и писал! Спасибо)
Действительно, не могу понять кого в 2013-м можно удивить революционной идеей виртуализации приложений
Это уже сделано в контейнерной виртуализации, когда разные ядра работают параллельно и используют версии библиотек. Почитайте openvz и глубже
А как предлагаете реализовать хранение профилей программ для различных пользователей?
вы изобрели ru.wikipedia.org/wiki/Aufs unionfs и т.п.?
Спасибо за ссылки, мои попытки гуглить «Cascade File System» не навели на них. Уже изучаю)
просто сталкивался — они много лет используются в livecd для сохранения изменений или совместно с jail/vserver(для экономии места).
также есть реализации на базе fuse. и советую почитать про неймспейсы в plan9, там много подобных идей и всякого ещё.
и ещё в btrfs есть cow — позволяет делать мгновенные снапшоты и потом переключаться между ними. т.е. можно примонтировать отдельно определенный снапшот и работать с ним-изменения будут записываться.
также есть реализации на базе fuse. и советую почитать про неймспейсы в plan9, там много подобных идей и всякого ещё.
и ещё в btrfs есть cow — позволяет делать мгновенные снапшоты и потом переключаться между ними. т.е. можно примонтировать отдельно определенный снапшот и работать с ним-изменения будут записываться.
А когда джейлбрэйк появятся?
Но не всегда приложение должно работать в своей песочнице, не редко им требуется выход из неё для модификации системных файлов либо получения повышенных привилегий. Для этого можно использовать стандартную систему привелегий пользователей для записи в «чужие» образы.
В итого: приложение А взаимодействует с приложением Б, имеет на это все полномочия. Файл Х обрабатывается и А и Б. Я удаляю приложение Б — и:
1) Файл Х, находящийся в контейнере Б, удаляется вместе с ним. После запуска приложение А недоумевает: где файл, с которым оно работало?
2) Файл Х остаётся. В таком случае имеем в системе хвосты от приложения Б.
3) Файл Х остаётся только в том виде, в котором его меняло приложение А. Все изменения от Б исчезают. Имеем кучу головной боли, потерю промежуточных версий и полную неразбериху. Плюс — дополнительный затрат ресурсов системы для отслеживания изменений в Х от правки к правке.
Решение напоминает песочницу любого портабелизатора. Решение удобно для частных случаев, и вряд ли имеет право на жизнь в рамках ОС.
Почитайте про Plan9, вам понравится.
Около полугода назад мне пришла в голову оочень похожая идея. Только я свою идею подчерпнул не из Mac OS, а из Android, хотя принципиальной разницы нет — они ведь там тоже похожи. Если интересно, пишите в ЛС, можем вместе пофантазировать.
Я хочу реестр с возможностью монтирования веток. Тогда при удалении приложения его ветка отмонтируется и не оставит мусора.
Единственное, для чего это нужно — избежать конфликтов при установке ПО и добиться удаления всех данных вместе с приложением. Эта проблема уже решена в *nix системах.
Приложения устанавливаются и удаляются централизовано, системе известно о всех файлах и всех конфликтах. Общие настройки хранятся в /etc/, и обычно успешно удаляются вместе с приложением, настройки пользователя — в ~/.*, они сохраняются после удаления приложения, но никто не мешает убрать их в одно действие. Никаких проблем с чисткой системы, если самостоятельно ничего не ломать.
Сейчас в меня полетят камни по поводу софта, которого нет в репозиториях, но я считаю, что завернуть приложение в пакет, прежде чем ставить на систему — простое действие, которое по силам каждому (сам иногда ebuild-ы пишу).
Приложения устанавливаются и удаляются централизовано, системе известно о всех файлах и всех конфликтах. Общие настройки хранятся в /etc/, и обычно успешно удаляются вместе с приложением, настройки пользователя — в ~/.*, они сохраняются после удаления приложения, но никто не мешает убрать их в одно действие. Никаких проблем с чисткой системы, если самостоятельно ничего не ломать.
Сейчас в меня полетят камни по поводу софта, которого нет в репозиториях, но я считаю, что завернуть приложение в пакет, прежде чем ставить на систему — простое действие, которое по силам каждому (сам иногда ebuild-ы пишу).
вы почти повторили мою идею о системе виртуализации уровня ОС в виде дерева-песочниц, когда-то озвученную на одном сайте
сейчас этой темы там уже нет, ибо регулярно чистятся
идея такова
есть иерархия песочниц
в корне — «живая» ОС
её дети — песочницы
у них тоже могут быть дети-песочницы, и т.д.
проги из песочницы-родителя могут делать что угодно с прогами в песочницах-потомках: читать память, писать память, запускать треды (треды стартуются с в потомке), инжектить код и т д
потомки рулить предками не могут
разве что по инициативе предка
все изменения в предке незамедлительно или отложено отражаются на потомке
изменения в потомке на предке не отражаются
проги в песочницах одного уровня, являющиеся потомками одного родителя могут взаимодействавать, если это явно разрешено правилами (что-то в роде «процессам из песочницы а1 разрешено запускать браузер в песочнице а2» или «проге б из песочницы а1 разрешено ставить мьютекс трололо, который будет виден в песочнице а2»).
сейчас этой темы там уже нет, ибо регулярно чистятся
идея такова
есть иерархия песочниц
в корне — «живая» ОС
её дети — песочницы
у них тоже могут быть дети-песочницы, и т.д.
проги из песочницы-родителя могут делать что угодно с прогами в песочницах-потомках: читать память, писать память, запускать треды (треды стартуются с в потомке), инжектить код и т д
потомки рулить предками не могут
разве что по инициативе предка
все изменения в предке незамедлительно или отложено отражаются на потомке
изменения в потомке на предке не отражаются
проги в песочницах одного уровня, являющиеся потомками одного родителя могут взаимодействавать, если это явно разрешено правилами (что-то в роде «процессам из песочницы а1 разрешено запускать браузер в песочнице а2» или «проге б из песочницы а1 разрешено ставить мьютекс трололо, который будет виден в песочнице а2»).
А как вы будете решать проблему несовместимости разных версий библиотек?
Т.е. есть у приложения A библиотека ZIP версии 1.0, а у приложения Б такая же библиотека ZIP, но версии 3.55, являющийся не совместимой с библиотека приложения А.
Т.е. есть у приложения A библиотека ZIP версии 1.0, а у приложения Б такая же библиотека ZIP, но версии 3.55, являющийся не совместимой с библиотека приложения А.
www.opennet.ru/opennews/art.shtml?num=36043
я просто оставлю эту ссылку здесь: разработчики Gnome думали в таком же направлении и в общем-то задачу решили.
UPD: выше эту ссылку уже привели, так что добавлю от себя: сама идея статической сборки и изоляции приложений мне не нравится. на мой взгляд это может излишне усложнить системный софт и привести к повышенному потреблению аппаратных ресурсов.
я просто оставлю эту ссылку здесь: разработчики Gnome думали в таком же направлении и в общем-то задачу решили.
UPD: выше эту ссылку уже привели, так что добавлю от себя: сама идея статической сборки и изоляции приложений мне не нравится. на мой взгляд это может излишне усложнить системный софт и привести к повышенному потреблению аппаратных ресурсов.
Когда-то давно наткнулся на один фреймворк. Он поставлялся как часть дистрибутива Super OS (очередной bolgenos), но его можно было установить и на убунту.
Ещё один вариант реализации этой же идеи: AppImageKit
Оба варианта в общем-то реализуют вашу идею.
Ещё один вариант реализации этой же идеи: AppImageKit
Оба варианта в общем-то реализуют вашу идею.
Sign up to leave a comment.
Cascade File System или размышления о файловой системы моей мечты