Board.KolibriOS.org

CleverMouse wrote:Рамдиск - это не костыль, это функциональность, одно из средств, благодаря которым Колибри работает быстро. Вы хотите, чтобы система на каждый чих лезла на винт?

Что ж, будь по-вашему - это не костыль, а фича
И тем не менее - важна возможность этой фичей не пользоваться, по усмотрению пользователя.

Я, собственно, с самого начала догадывался, что "молниеносность" запуска ПО обеспечивается скоростью работы ввода\вывода, что, как я считал, скорее всего является следствием расположения системных файлов на виртуальном диске, в памяти ОЗУ. И оказался, таки, прав, помотав вдоволь себе и всем нервы над пониманием принципа инсталляции ОС )

Пусть лезет.
Я, конечно, понимаю, что "узким местом" станет в этом случае винчестер - но я вот так вот не могу разбираться и работать, когда всё через какие-то "выверты"...
Воспользоваться этой фичей я могу в любой момент, но для целей тестирования МНЕ так будет удобнее.

---
Извините за лирическое отступление, но мне вот 4 человека пытались объяснить: что и как работает - ничерта не понятно, сплошные "рецепты" для безруких, а не теор часть.
У меня своя голова есть, я если разберусь в ТЕОРИИ - то сам добьюсь того, что нужно, мне не нужны готовые рецепты.
Я хочу понять КАК ЭТО РАБОТАЕТ и вникнуть в теорию.
А её нет - нет даже терминологии человеческой в описании "install.txt", буквально всё и так "само собой разумеется для тех кто в теме"... Как издевательство.

Приходится вникать методом Reverse Engineering и пытаться строить догадки...
Вам-то всё очевидно, но стороннему человеку, который искренне хочет помочь и пытаться разобраться - это значит на каждом шагу ломать себе ноги об разнообразные фичи, запутывающие прямой путь к восприятию системы.

---
P.S. Постараюсь в ближайшее время подготовить свой вариант "кристально-понятной" инструкции install.txt и предоставить всем на оценку. На обоих языках.
Опыт разработки технической документации имеется (4+ года).
Если понравится и захотите внедрить мой вариант - буду рад помочь.

Fanatic wrote:но я вот так вот не могу разбираться и работать, когда всё через какие-то "выверты"...

Почему вы считаете рамдиск "вывертом"?

Fanatic wrote:Пусть лезет.

Для приложений, запускаемых ядром, этого не будет. Другие приложения можете запускать откуда угодно. При желании можете в autorun.dat, menu.dat, icon.ini прописать пути на винте - тогда launcher, @menu и @icon соответственно будут дёргать винт.

Fanatic wrote:мне вот 4 человека пытались объяснить: что и как работает - ничерта не понятно, сплошные "рецепты" для безруких, а не теор часть.

Вы спрашиваете "как мне это сделать" - вам пытаются объяснить, как это сделать. Хотите знать, что внутри, - так и спрашивайте. install.txt - это инструкции, что делать, а не как оно работает. Вас интересует что-то конкретное?

Fanatic wrote:Опыт разработки технической документации имеется (4+ года).

По стилю речи понятно, что есть опыт разработки технической документации. Правда иногда такую речь труднее воспринимать даже, чем вольное изложение, несмотря на кристальность терминологии и попытку объять все возможные варианты. Пример - различные государственные законы (по крайней мере в РБ). Порой кажется, что для этого нужен какой-то особый склад ума.

CleverMouse wrote:

Fanatic wrote:Пусть лезет.

Для приложений, запускаемых ядром, этого не будет.

По какой причине?
Почему ядро неспособно обращаться ко всем требуемым для его работы файлам, если они расположены непосредственно на носителе, рядом с ним?
Над чем конкретно и какие именно потребуются усилия чтобы реализовать требуемое?
И последнее: известно, что такая возможность была раньше. Почему сейчас вопрос с обсуждаемым обстоит как "невозможно", вместо "теоретически возможно, но работа не гарантируется"?

Исходя из теории, загрузчик должен передавать управление ядру ОС, которое, в свою очередь, загружает всё что ему требуется в память ОЗУ. Я не против, чтобы ОС помещала свои данные в ОЗУ - собственно, я и не могу быть против этого, так ОС работает - я против того, чтобы она БРАЛА данные из образа.
Хорошей иллюстрацией служит пример с игровым ПО, где запускаемое приложение может брать нужные ему данные из образа в PAK-файле, а может непосредственно загужать данные из файлов, расположенных в заданных местах. Последнее удобно, когда происходит отладка "дополнений" и делается живая замена файлов прямо на диске, без необходимости каждый раз собирать PAK-образ.

Fanatic wrote:По какой причине?

Главным образом, по идеологической.

Fanatic wrote:Почему ядро неспособно обращаться ко всем требуемым для его работы файлам, если они расположены непосредственно на носителе, рядом с ним?

Потому что для работы с носителем нужен ещё и драйвер носителя. Драйвер IDE встроен в ядро только по историческим соображениям. Как и файловые системы, впрочем. Драйвера USB-флешек и SATA - отдельные файлы, которые надо прочитать до того, как будет возможна полноценная работа.

Fanatic wrote:И последнее: известно, что такая возможность была раньше. Почему сейчас вопрос с обсуждаемым обстоит как "невозможно", вместо "теоретически возможно, но работа не гарантируется"?

Она и раньше скорее не работала, чем работала. Минус полтора метра памяти под неиспользуемый рамдиск, жёсткая привязка к координатам на IDE, необходимость наличия DOS. И главное - отсутствие поддержки при изменениях ядра, которых с того момента было много.

Fanatic wrote:Исходя из теории, загрузчик должен передавать управление ядру ОС, которое, в свою очередь, загружает всё что ему требуется в память ОЗУ.

У вас неточные представления о теории. Загрузчик должен загрузить не только ядро ОС, но и данные, необходимые для инициализации. В Linux точно так же грузится образ рамдиска, только там он read-only и, соответственно, не FAT, а что-то вроде squashfs. В Windows загрузчик читает реестр и загружает драйверы, указанные в нём.

Fanatic wrote:Над чем конкретно и какие именно потребуются усилия чтобы реализовать требуемое?

Есть вариант заставить загрузчик создавать FAT-образ динамически при загрузке по отдельным файлам, чтобы с точки зрения ядра оставался /rd/1, но kolibri.img был бы виртуальной сущностью, не присутствующей в виде отдельного файла. Для не слишком толкового, но и не совсем бестолкового, разработчика - ориентировочно месяц разработки.

CleverMouse wrote:

Fanatic wrote:Почему ядро неспособно обращаться ко всем требуемым для его работы файлам, если они расположены непосредственно на носителе, рядом с ним?

Потому что для работы с носителем нужен ещё и драйвер носителя. Драйвер IDE встроен в ядро только по историческим соображениям. Как и файловые системы, впрочем. Драйвера USB-флешек и SATA - отдельные файлы, которые надо прочитать до того, как будет возможна полноценная работа.

Вот где всё дело, докопался! Большое спасибо.
Теперь всё становится на свои места: даже если встроить поддержку SATA и USB на уровне ядра, то в случае потребности в малейших изменениях драйвера или банального апдейта поддержки устройств - каждый раз потребуется правка ядра, что явно не целесообразно.

Но, к сожалению, как раз именно этот вариант - и есть искомый )))))))))))
Боюсь даже спрашивать, сколько потребовалось бы человекочасов на встраивание USB- или SATA-драйвера на уровне ядра, хотя бы в том виде, в котором драйвера сейчас есть...

CleverMouse wrote:

Fanatic wrote:Над чем конкретно и какие именно потребуются усилия чтобы реализовать требуемое?

Есть вариант заставить загрузчик создавать FAT-образ динамически при загрузке по отдельным файлам, чтобы с точки зрения ядра оставался /rd/1, но kolibri.img был бы виртуальной сущностью, не присутствующей в виде отдельного файла. Для не слишком толкового, но и не совсем бестолкового, разработчика - ориентировочно месяц разработки.

Теоретически способ вполне работающий.
Насколько я понимаю: виртуальный образ собирался бы при каждой загрузке из того, что находится на носителе. С изменением содержимого на носителе - содержимое собираемого при загрузке виртуального образа изменяется.
А как загрузчик увидит файлы на носителе?..

Fanatic wrote:А как загрузчик увидит файлы на носителе?..

Так же, как он сейчас видит файл kolibri.img.

Heavyiron wrote:

Fanatic wrote:Опыт разработки технической документации имеется (4+ года).

По стилю речи понятно, что есть опыт разработки технической документации. Правда иногда такую речь труднее воспринимать даже, чем вольное изложение, несмотря на кристальность терминологии и попытку объять все возможные варианты. Пример - различные государственные законы (по крайней мере в РБ). Порой кажется, что для этого нужен какой-то особый склад ума.

Иногда бывает и так
Как мы знаем, капиталистическому миру присуща анархия производства и отсутствие взаимоувязанной целостности во всём, поэтому любые стандарты изменяются так часто и настолько быстро, что конкретные инструкции столь же быстро устаревают. И инструкции приходится столь же часто обновлять.
В условиях свободной разработки это превращается в адскую мешанину: кто-то каждый раз вносит правки ссылаясь на что-то, второй дополняет и не учитывает ссылки, третий вносит ещё одни дополнения в уже третьи материалы и со временем этот ворох разобщённых инструкций разрастается до таких масштабов, что разобраться в них становится огромной анальной болью и нервотрёпкой: пытаешься собрать мозаику воедино, но у тебя ничего не получается кроме разрозненных огрызков, из которых ни черта не ясно. На вики одно, там другое, в доках третье, на сайтах четвёртое, на форуме - пятое...

Я считаю, чтобы это побороть нужно максимально донести саму идею того, как ведёт себя ОС и что ей нужно. Человек сможет сам собрать себе систему в соответствии со своими потребностями и сам выбрать метод.

CleverMouse wrote:

Fanatic wrote:А как загрузчик увидит файлы на носителе?..

Так же, как он сейчас видит файл kolibri.img.

Понял, стормозил.
Что ж, это был бы отличный вариант.

Fanatic wrote:Я считаю, чтобы это побороть нужно максимально донести саму идею того, как ведёт себя ОС и что ей нужно. Человек сможет сам собрать себе систему в соответствии со своими потребностями и сам выбрать метод.

Если сюда заглянет Leency, он расскажет, что пользователю нужно только знать, какие кнопочки нажимать, и ни в коем случае не смотреть внутрь. В идеале инструкция должна содержать три строчки, которые один раз сработали у Leency, и ни в коем случае не грузить пользователя вариантами.

Well, никто не мешает иметь короткий мануал для тех, кто хочет результат, и длинный для тех, кому важны детали.

Конечно же, если какие-то строчки сработали на компьютере Leency, это автоматически даст результат на любом компьютере с любым железом под любой операционной системой, поэтому все остальные строчки можно выкинуть или задвинуть куда-нибудь подальше.

Leency довел до крайности, ты уводишь в другую крайность. Запутанные непонятные мануалы - это плохо.

SoUrcerer wrote:По поводу сохранения - вы, вероятно, стали жертвой SaveDialog. Чтобы сохранить файл, недостаточно выбрать папку. Нужно щелкнуть по полю ввода имени файла, и лишь затем нажать Save. Попробуйте.

Вообще то если быть более точным в выражениях и логически последовательным, то фокус выборы должен либо стоять в поле ввода имени, либо в области списка файлов и будет располагаться на файле. Если же он на директории или на "..", то кнопка "Save" меняет текст на "Open" и тогда действительно нужно переключать фокус на область ввода имени файла.

З.Ы. Если кто то более умный и способный сделает OpenDialog лучше - я сам лично своими руками выпилю текущий OpenDialog из дистрибутва и SVN. Поскольку выслушивать каждый раз голословные обвинения мне надоело. А пока нет альтернативы все будут "вкушать" то, что я приготовил. На этом обсуждение OpenDialog в этой теме считаю законченным.

Флуд, удалено.