Автомонтирование дополнительного раздела с приложениями

Internal structure and you change requests/suggestions
  • Где-то есть ограничения 8.3. UUID не поместится.
  • Меня мучает вопрос - как генерировать UUID. Желательно, чтобы была возможность во всех средах (Win/Linux/Kolibri) получать одинаковые результаты.
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • Если программы будут размещены в отдельном разделе (томе), то мне кажется, что достаточно обойтись меткой тома фиксированного вида (типа $Kolibri$) и предусмотреть две метки -- системную и пользовательскую, где пользовательская перебивает системную с расчетом на фанатов "Колибри", имеющих собственный набор программ под нее, пополняемый вручную. Либо монтировать оба раздела по двум разным путям...

    Гм. Либо предусмотреть три метки:
    • Системная, работающая по умолчанию.
    • Пользовательская, перебивающая системную.
    • Пользовательская, дополняющая системную.
  • Mario_r4
    Утилит и исходников для генерации в сети много.
    Собственно почему я предлагаю UUID и монтирование на /sys.

    Для каждой языковой версии дистрибутива можно сделать свой UUID. Это упростит проверку установщиком и версии дистрибутива и языка установки.

    Подмена /sys уже реализована в ядре. Добавление ещё одной папки сделает довольно запутанный код ещё сложнее.
  • Serge wrote:Утилит и исходников для генерации в сети много.
    Раньше посылали... далеко в общем, а теперь в гугл.
    Собственно у меня идея делать для каждой ревизии свой UUID. В том числе генерация в самой Колибри нужна.
    Serge wrote:Подмена /sys уже реализована в ядре. Добавление ещё одной папки сделает довольно запутанный код ещё сложнее.
    Если так рассуждать, то любая последующая ревизия вообще делает код еще сложней и запутанней. Между тем грузить ВСЕ файлы с CD/DVD очевидно не выгодно в плане скорости.
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • Mario_r4
    CD/DVD должны проверяться в последнюю очередь.
    Собственно у меня идея делать для каждой ревизии свой UUID. В том числе генерация в самой Колибри нужна
    Сделать подмену макросом, как для svn:revision, а генерировать на сервере автосборок.
  • нужный раздел, с нужным контрольным файлом
    пустой файл с именем - UUID строкой
    Не совсем понял необходимость этого.
    требуется ручками прописать ассоциации в файловых менеджерах.
    Это должна делать программа-установщик(как это и происходит в других ос).
    Как сказал Mario_r4, нужна SysFn, которая умеет монтировать разделы(и не важно, что это за разделы). Тогда в autorun.dat можно написать что-то вроде: mount "/addappl".
    Если нужна ещё и установка чего-то, то добавить: /addappl/install.kex.
    Я думаю копирование их на темповский диск не всегда оправдано
    Между тем грузить ВСЕ файлы с CD/DVD очевидно не выгодно в плане скорости
    В любом случае изначально файлы находятся на CD/DVD, значит, всё равно какие-то из них нужно копировать на tmp. Этим и будет заниматься install.kex:
    если нет tmp, то создать, скопировать нужные файлы, установить ассоциации и т.п.
    если не получилось создать нужного размера tmp, то не копировать и установить другие ассоциации...
  • 0CodErr wrote:Не совсем понял необходимость этого.
    Система после загрузки знает только о наличии /rd/1, о наличии других мест где можно брать программы, бибилотеки, данные - она не знает. Нельзя жестко прописать запуск видеоплеера, к примеру с /cd0/1/ потому что нельзя гарантировать его наличие именно по этому пути. Метка позволяет просмотрев все известные диски и разделы найти нужный. Теперь достаточно понятно?
    0CodErr wrote:Это должна делать программа-установщик(как это и происходит в других ос).
    Подразумевался запуск Live системы.
    0CodErr wrote:Как сказал Mario_r4, нужна SysFn, которая умеет монтировать разделы(и не важно, что это за разделы). Тогда в autorun.dat можно написать что-то вроде: mount "/addappl".
    Если нужна ещё и установка чего-то, то добавить: /addappl/install.kex.
    Я не готов писать полноценный mount, да и для озвученной в теме идеи он не нужен.
    0CodErr wrote:В любом случае изначально файлы находятся на CD/DVD, значит, всё равно какие-то из них нужно копировать на tmp. Этим и будет заниматься install.kex:
    Еще раз - речь идет о Live системе и к моменту запуска у нас уже есть /rd/1/ с файлами. Загружать их не нужно, совсем не нужно.

    З.Ы. У меня создалось впечатление что ты не понял тему. Хотя речь идет о Live системе, возможность найти собственный раздел будет полезна и уже установленной системе. Пользователь может переподключить диск на другой контроллер, воткнуть еще одну флешку, кроме загрузочной и т.д.
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • Serge wrote:Сделать подмену макросом, как для svn:revision, а генерировать на сервере автосборок.
    А если пользователь желает сам собрать свой дистрибутив - ему что теперь UUID генерировать руками?
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • З.Ы. У меня создалось впечатление что ты не понял тему.
    Да, возможно, не совсем.
    Я не готов писать полноценный mount, да и для озвученной в теме идеи он не нужен.
    Но монтировать раздел всё равно нужно и новая SysFn?
    Нельзя жестко прописать запуск видеоплеера, к примеру с /cd0/1/ потому что нельзя гарантировать его наличие именно по этому пути.
    С одной стороны жёстко вообще ничего нельзя прописать(плееры могут быть разные, набор программ различаться). Но с другой стороны в конкретном дистрибутиве конкретный набор программ. Если прописать "/addappl/FPlay/fplay.kex", то, если плеер там будет, он запустится. Поэтому, если плеер у нас на cd\dvd, то нужно этот диск монтировать в "/addappl".
    Система после загрузки знает только о наличии /rd/1, о наличии других мест где можно брать программы, бибилотеки, данные - она не знает.
    Пользователь может переподключить диск на другой контроллер, воткнуть еще одну флешку, кроме загрузочной и т.д.
    Ядро ведь сейчас и так монтирует диски\флешки? А самому ядру для работы не нужно никаких программ.
    Метка позволяет просмотрев все известные диски и разделы найти нужный.
    Этот поиск будет происходить один раз при старте или постоянно во время работы?
    Ведь при переподключении диск отмонтируется и нужно будет снова его монтировать.
  • Почему вместо UUID нельзя использовать текстовый файл с содержанием <номер версии>+<номер ревизии>+<язык>+<опциональный текст для пользователя "этот файл служит для идентификации раздела /addappl или как его там"? Кажется, это более понятно для конечного пользователя.
    Сделаем мир лучше!
  • 0CodErr wrote:Но монтировать раздел всё равно нужно и новая SysFn?
    Я пока склоняюсь к предложению Serge - сделать код исключительно в ядре и он отработает до запуска приложения Launcher.
    0CodErr wrote:С одной стороны жёстко вообще ничего нельзя прописать(плееры могут быть разные, набор программ различаться). Но с другой стороны в конкретном дистрибутиве конкретный набор программ. Если прописать "/addappl/FPlay/fplay.kex", то, если плеер там будет, он запустится. Поэтому, если плеер у нас на cd\dvd, то нужно этот диск монтировать в "/addappl".
    Содержимое меню определяется его составителем, в вот гарантия расположения плеера по пути "/addappl/FPlay/fplay.kex" как раз будет гарантироваться схемой описанной в первом пункте это темы.
    0CodErr wrote:Ядро ведь сейчас и так монтирует диски\флешки? А самому ядру для работы не нужно никаких программ.
    Еще раз - ядро не знает точно откуда его загрузили. В настоящее время точная уверенность может быть лишь про наличие рамдиска.
    0CodErr wrote:Этот поиск будет происходить один раз при старте или постоянно во время работы?
    Ведь при переподключении диск отмонтируется и нужно будет снова его монтировать.
    А как думаешь Linux Live CD работает? Если заставить систему отдать CD диск (а сделать это не просто, так как разработчики обычно отключаю такую возможность) - Linux тоже будет очень "удивлен" отсутствию диска. Загрузочное устройство нельзя вынимать до завершения текущего сеанса работы. И это вторая причина почему я не хочу брать все файлы тупо смонтировав на /sys - в случае если пользователь дурак и вынул таки диск, у системы еще останется рамдиск с самыми важными приложениями и данными.
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • CleverMouse wrote:Почему вместо UUID нельзя использовать текстовый файл с содержанием <номер версии>+<номер ревизии>+<язык>+<опциональный текст для пользователя "этот файл служит для идентификации раздела /addappl или как его там"? Кажется, это более понятно для конечного пользователя.
    Можно и так - для меня не приципиально, главное чтобы файлы совпадали до бита и если пользователь отредактировал один файл, то должен дублировать его на второй.
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • А если пользователь желает сам собрать свой дистрибутив - ему что теперь UUID генерировать руками?
    А что мешает ? Так же как и lang.inc создавать.
    Почему вместо UUID нельзя использовать текстовый файл с содержанием <номер версии>+<номер ревизии>+<язык>+<опциональный текст для пользователя "этот файл служит для идентификации раздела /addappl или как его там"? Кажется, это более понятно для конечного пользователя.
    Кому как. Меня например парсинг строк ставит в тупик.
    Идея была в том, что в корневом разделе диска создаётся каталог /KolibriOS и файл с совпадающим UUID именем подтверждает, что это именно тот каталог, который нужно смонтировать на /sys. В конце концов разделов с /KolibriOS может быть несколько, а поиск по имени файла раза в два быстрее поиска с последующим чтением. Это не мешает хранить в файле дополнительную информацию, например настоящий путь к программам KolibriOS.

    Тогда так. В корневом каталоге хранится UUID файл, в котором записана вся информация необходимая ядру для монтирования /sys. Такой вариант позволит одновременно держать несколько разных дистрибутивов.
    Таким способом можно делать многоязычные CD.
  • Who is online

    Users browsing this forum: No registered users and 9 guests