В связи с планами выпуска дистрибутива 1.0.0.0, встает вопрос с ISO образом. Нынче на нем содержатся дополнительные программы, которые не влезли в образ рамдиска. Пользователь может их запускать, но разумеется для полноценной работы требуется ручками прописать ассоциации в файловых менеджерах. Разумеется это не годный подход.
Давно уже всплывала тема как дать загруженной системе знать, где находится диск с дополнительными приложениями. ЕМНИП первым предложил Serge - располагать контрольный файл, по которому система найдет нужный диск и раздел. Однако идея был не до конца проработана в деталях.
Предлагаю тут обсудить реализацию. Вот как я ее вижу.
Система при старте запускает не Launcher, а приложение, которое будет искать нужный раздел, с нужным контрольным файлом. Копия такого-же файла будет лежать на рамдиске, для быстрой смены образа без перекомпиляции. Если файлы совпадут по содержимому, то программа вызывает системную функцию, которая добавляет в корневой раздел ("/" ) диск с названием допустим "/addappl" и создает линк на найденный раздел (название не так принципиально, лишь бы не совпадало с уже существующими, например можно обозвать "/sys2"), который будет вторым после "/sys" приложением. Можно монтировать дополнительную директорию не в "/", а в "/sys", но такого кода у нас пока принципиально нет. Далее мы уже просто пользуемся, вызывая с использованием пути "/addappl/media/fplay", например для видеоплеера.
Есть один минус, который одновременно и плюс - никто не мешает во время работы ВНЕЗАПНО подменить директорию. Прав доступа у нас нет, потому я думаю можно на первых порах этот функционал в ядре сделать, чтобы не рожать дополнительных системных функций и обеспечить неизменность директории в продолжении хотя бы одного сеанса. С другой стороны в данный момент никто не мешает подменить "/sys" - или я уже путаюсь и оно не доступно к смене через системную функцию ядра?
В общем высказывайтесь, критикуйте - я не отрицаю что мои идеи и код на 90% говно, но для того здесь коллективный разум сообщества присутствует.
Автомонтирование дополнительного раздела с приложениями
-
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
А ещё есть замечательный tmpdisk, с которого программы загружаются очень быстро. Многие live-системы грузят своё содержимое в память, и работают оттуда. Не панацея, потому что увеличивает время загрузки системы в целом. В общем-то, даже на 4x CD-ROM дополнительные файлы размером 20 Мб будут считываться аж 40 секунд, а на 52x - целых 4.
SoUrcerer
И часто нам нужно запускать видеоплеер и другие толстые приложения? Я думаю копирование их на темповский диск не всегда оправдано. ALT Linux Live например прекрасно запускает такие приложения с самого исходного диска. К тому же наличие темповского раздела не решает проблемы с обнаружением исходного системного раздела, который может быть как на CD, DVD, так и на HD, USB, BD.
И часто нам нужно запускать видеоплеер и другие толстые приложения? Я думаю копирование их на темповский диск не всегда оправдано. ALT Linux Live например прекрасно запускает такие приложения с самого исходного диска. К тому же наличие темповского раздела не решает проблемы с обнаружением исходного системного раздела, который может быть как на CD, DVD, так и на HD, USB, BD.
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
Не решает. Ты прав.
Но концепция поиска и монтирования как /sys/somewhat/ мне нравится.
Но концепция поиска и монтирования как /sys/somewhat/ мне нравится.
Mario_r4
Не по содержимому, пустой файл с именем - UUID строкой. И лучше делать это ещё в ядре. И монтировать на /sys, для подмены которой уже написан код.
Не по содержимому, пустой файл с именем - UUID строкой. И лучше делать это ещё в ядре. И монтировать на /sys, для подмены которой уже написан код.
Не есть хорошо с точки зрения ограничения на отдельные символы на разных файловых системах. У того что предложил я - нет ограничений на саму сравниваемую строку и ее длину - уникальность нужна.Serge wrote:Не по содержимому, пустой файл с именем - UUID строкой.
Монтировать с заменой "/sys" также не совсем хорошо - рамдиск работает быстрее и желательно "/sys" = "/rd/1", чтобы грузить основной набор программ именно с рамдиска.Serge wrote:И монтировать на /sys, для подмены которой уже написан код.
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
Вам не передать как я рад, что кто-то наконец в глобальном слысле подошёл к проблеме. Она в некотором смылсе уже решённа в KolibriN.
>>приложение, которое будет искать нужный раздел, с нужным контрольным файлом
именно такое приложение в KolibriN: http://websvn.kolibrios.org/listing.php ... 300457094c
запускается, ищет, и запускает установщик
Изначально было два варианта:
1. использовать файлы с того места, где мы их нашли
2. или копировать на tmp-диск
Плюсы первого варианта - не нужно копировать файлы. Быстрее приступаем к работе.
Плюсы второго варианта - долго копируем. Зато всё очень быстро запускается и диск на котором были ориг. файлы (CD/flash) можно извлечь.
Чесно: я не знаю какой вариант лучше. И всё же было бы неплохо завести ещё одну переменную типа /sys/ вроде /soft/ или любое другое название. Второй вариант не исключает первого.
>>приложение, которое будет искать нужный раздел, с нужным контрольным файлом
именно такое приложение в KolibriN: http://websvn.kolibrios.org/listing.php ... 300457094c
запускается, ищет, и запускает установщик
Изначально было два варианта:
1. использовать файлы с того места, где мы их нашли
2. или копировать на tmp-диск
Плюсы первого варианта - не нужно копировать файлы. Быстрее приступаем к работе.
Плюсы второго варианта - долго копируем. Зато всё очень быстро запускается и диск на котором были ориг. файлы (CD/flash) можно извлечь.
Чесно: я не знаю какой вариант лучше. И всё же было бы неплохо завести ещё одну переменную типа /sys/ вроде /soft/ или любое другое название. Второй вариант не исключает первого.
Из хаоса в космос
Как вариант, программы которые предположительно используются наиболее часто копировать на tmp-диск, а остальное запускать оттуда, где были найдены.Leency wrote:Изначально было два варианта:
1. использовать файлы с того места, где мы их нашли
2. или копировать на tmp-диск
Плюсы первого варианта - не нужно копировать файлы. Быстрее приступаем к работе.
Плюсы второго варианта - долго копируем. Зато всё очень быстро запускается и диск на котором были ориг. файлы (CD/flash) можно извлечь.
Чесно: я не знаю какой вариант лучше. И всё же было бы неплохо завести ещё одну переменную типа /sys/ вроде /soft/ или любое другое название. Второй вариант не исключает первого.
to infinity and beyond
Тоже вариант. В KolibriN сейчас копирование запускается вручную и требует времени. Если этот процесс запустить в фоне после старта системы и начать копирование с самых маленьких/часто испольумых программ, то пользователь этот процесс может и не заметить.
Из хаоса в космос
В идеале можно было бы сделать еще никий файл со списком программ которые необходимо скопировать, таким образом человек смог бы настроить процесс опираясь на свои нужды.
to infinity and beyond
1. Код в С-- это не мой выбор.Leency wrote:Она в некотором смылсе уже решённа в KolibriN.
>>приложение, которое будет искать нужный раздел, с нужным контрольным файлом
именно такое приложение в KolibriN: http://websvn.kolibrios.org/listing.php ... 300457094c
запускается, ищет, и запускает установщик
Изначально было два варианта:
1. использовать файлы с того места, где мы их нашли
2. или копировать на tmp-диск
2. Судя по твоей сборке - она ничего не монтирует автоматически, тем более это никак не поддержано со стороны ядра. Так что такое решение в лучшем случае половинчатое и непрактичное.
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
Тем не менее, нельзя отрицать, что это решение. И это решение таки решает кое-какие проблемы большинства простых пользователей, которые хотят, чтобы оно "просто работало". Видимо, направление верное. Вопрос в реализации.
А еще мне очень нравится идея кастомных сборок на сервере. Чтобы можно было собрать и систему в 200 кб, и полностью нашпигованную софтом.
А еще мне очень нравится идея кастомных сборок на сервере. Чтобы можно было собрать и систему в 200 кб, и полностью нашпигованную софтом.
Можно написать веб-морду, которая передает выбранные пользователем пункты для сборки - я не думаю, что это настолько сложно. А готовая ссылка например хранится в течение часа. Разумеется необходимый минимум будет гарантированно присутствовать в образе рамдиска, а все опциональное запихиваться в ISO. Также нужно будет корректировать menu.datSoUrcerer wrote:А еще мне очень нравится идея кастомных сборок на сервере. Чтобы можно было собрать и систему в 200 кб, и полностью нашпигованную софтом.
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
Раньше такое было в Slax, но теперь убрали. Зато есть в Angstrom:
http://narcissus.angstrom-distribution.org/
http://narcissus.angstrom-distribution.org/
>>Она в некотором смысле уже решённа в KolibriN. Вам не передать как я рад, что кто-то наконец в глобальном слысле подошёл к проблеме.Mario_r4 wrote:1. Код в С-- это не мой выбор.
2. Судя по твоей сборке - она ничего не монтирует автоматически, тем более это никак не поддержано со стороны ядра. Так что такое решение в лучшем случае половинчатое и непрактичное.
Пожалуйста, читай внимательно и старайся уловить суть. У меня был опыт, я им поделился. Моё решение далеко не оптимальное и хорошо, что ты поднял этот вопрос, чтобы решить его на уровне ядра/системы.
Из хаоса в космос
Who is online
Users browsing this forum: No registered users and 3 guests