Какие на данный момент есть наиболее приоритетные задачи?

Find out what others think about your ideas
  • Mario wrote:Уже было.
    Если ты про это, то Paypal там никогда не было, а с Webmoney далеко не уедешь.
  • maximYCH wrote:Дело не движется, совершенно.
    не факт, на самом деле. Просто многие, предпочитают сначала, довести что либо (вопрос, тему, идею, проект...) до некоторого уровня кондиции (хотябы идейный экватор 50%), а уже потом предлагать, освещать, выкладывать, обсуждать и развивать, "мутить сознание масс", так сказать. Ну и хотябы для того, чтобы позорно не обкакаться перед людьми в собственной несостятельности.
    maximYCH wrote:Давайте откроем фонд помощи, расскажем о нем на ХабраХабре, ВАСМе и других проектах?
    ну серьезные, матерые разрабы не пойдут на это, т.к. это для них лишь забава и детский лепет в песочнице. Вопрос зиждется на личностном идейном патриотизме хобби-направления + личный энтузиазм + фанатизм некоторый... любой фонд, любые деньги ничего не решают конкретно в качественном итоге кодинга, его перспективности, идейной далекоглядности для будующих разработок и продвижения конкретно ОСи! Мало того, там где будут возникать хорошие деньги, можно ожидать внезапно возникающих энергичных "разработчиков", цель которых отнюдь не развитие проекта или ему помощь (особенно архитектурно-идейная, концептуальная, итогово-рыночная например).
    Возникает вонючий вопрос менеджмента.
    Вонючий, потому, как возникает пересечение вопросов: деньги, справедливость, объективность, предвзятость, конкуренция, человек - человеку крокодил и т.д.
    Свобода, даже корявая и хаотичная диаметральна вонючности...
    Другое дело товарищеская взаимопомощь, включая материальные вещи, деньги, взаимовыгода не исключение. Но первая фаза межличностное доверие, для этого нужно хотябы иметь представление о личности, ее качествах и недостатках, возможностях...
    maximYCH wrote:А исходя из суммы, которую перечислят можно уже будет проводить конкурс нужных разработок.
    выше про это тоже ясно сказал. Исходно в текущем разрезе дел, это пожалуй абсурд, заблуждение, иллюзия.
    maximYCH wrote:Кто и как относится к этой идее?
    Просто хочется дело с мертвой точки сдвинуть.
    да двигает, я думаю тут каждый, кто периодически и на протяжении... лет тут присутствует.
    Просто этот каждый двигает:
    - как может
    - куда может
    - когда может
    - как ошибочно может двигает....
    Свобода и Хобби в разной степени индивидуального идиотизма фанатизма. Вот и все
  • гм, гм, гм... "краткая справка" по п.1 ТС:
    XVilka wrote: ------------------
    1. Загрузка с HDD
    1.1. есть предложение с моей стороны о реализации в адрес ТС и оно принято им (ведется весьма редкая переписка в силу двусторонней занятости, с XVilka о наших личных и удобных взаимовыгодных решениях вопросов)

    2. наличиствует концепт загрузки (т.е. гораздо шире вопросы, нежели просто фраза "Загрузка с HDD") и дореализации того, что у меня давно имеется (поднятие исходников, идейное и кодерское допиливание и усовершенствование, как наследие замершего проекта АтомОС (2004-2006)г.).
    Таким образом п.1. превращается в 3 шт. - ВРВ под FAT12, FAT16, FAT32 но в свете унифицированного обоснованного идейно принципа загрузки (из одноименного каталога на диске) и развороте ядра (затрагиваются еще вопросы на самом деле, т.к. автор видит причины и связку причин и позитива такого решения), передача параметров... Короче тут теория и описание нуна..... пока лень и некогда. Но можно. Потом.

    3. В соответствии с концептом готовность и отладка кода сбственно 3-х: BPB12, BPB16, BPB32 - 100%
    Исправлены ошибки LBA имевшиеся в BPB32 минипроекта AcroBoot (создан еще для MenuetOS), ну и другой ассемблерный дзен - оптимизинг по объему!.
    На код бут сектора загрузчика+сообщения отводится стандартом 448(420) байт. Основная сложность концепта поиск и загрузка ядра с каталога, без ущербности, а даже наоборот.
    Несмотря на вынос мозга оптимизингом, могу сказать, что все состоялось + даже расширенны текстовые сообщения по ошибкам(типажу) во всех BPB. Унификация удалась, концепт в этой части - состоялся.
    В текущем виде залежалый код "перекопан" на 50-60% в позитивном русле.

    3.1. Обкатано на 3 разных машинах, на разных дисках (включая несколько USB носителей), разные разделы дисков разной локации в их геометрии местарасположения (сначала, в середине, в конце). Для этого диски принудительно переразбивались(передвигались) и переформатировались PartitionMagicАми в реальностях жизни, а не какой то там виртуальной реальности виртуальной дисковости пространства!

    3.2. возникли ряд ПРАКТИЧЕСКИХ вопросов, типа, а как быть непосвященному разрабу, чайнику, новичку... короче
    Вопрос о фактической инсталляции BPB и применибельности.
    О возможности добавления (прописывания) в бутменеджеры, хотябы тот же boot.ini для NTLDR...
    Винда поди у всех то имеется, нельзя пренебрегать фактом.
    И не всем же надо BPB менять, потом хочется ведь и выбор привода наглядно и раздела диска.... включая USB.
    А это получается вообще то, что нужен инсталлятор(!!!??? какбЭЭЭ не совсем п.1 если добуквенно подходить ).
    Т.е. если по-людски, по-взрослому этот п.1 реализовывать то с практической, юзерской точки, а не кодерской видится следующая цепочка:
    Инсталлятор BPB (тип FS, тип диска, тип привода...) и каталога и файла ядра в нем (пока упрощенно так).
    Возникает ряд и вопросов и реализации дабы... дабы это было целостно, а не кусок. Вот типа загрузчик есть. Точка делай с ним что хош. Хош, считай, что он у тебя есть и когда то у кого то работал... Это ненорма. Думаю, что многие меня поддержат.
    Эволюционно на текущий момент, считаю нормальным решение вопросов всей цепочки по загрузке.
    Загрузка образа диска не должна быть основным принципом и многие это видят, столкнулись и как то для себя решили или обошли вопрос. Это временно, это несерьезно и это не должно нормой. А вот "загрузка ОС начиная от бутсектора(да хоть и PXE! Любого и на любом диске, разделе...) - до самостоятельной загрузки (дозагрузки, докачки) ядром всего, что ему еще там надо" (например в силу потребности в драйвере с неким ID в каталоге....) это претендент на принцип, на концепт.
    И самое смешное, что ничего загадочного или супернового или суперсложного в этом нет.

    3.3. В этом самом вопросе инсталла у меня есть текущие и мыслишки и задумки и наработки и кодинг-прогресс имеется, но он сильно варьиуется сейчас... Скажу только, что сейчас он в грубых черновиках пишется, как app win32 delph7+kol (вес 40КВ) в силу некоторых аргументов.
    В частности опять же винда у всех и везде, а значит широкого распространения весТЧЬ + всякие любимые Вами выставки, презентации + легкость распространяемости.
    А с точки зрения пиара великолепная презент-эффектность самого инсталла измеряемого в секундах!
    Когда ВСЕ(!?) привыкли, что инсталл сегодня...- это надо идти курить\пить кофе!
    Ну если не видиоролик, то чуден сам процесс в наглядности.
    Юзверь нажал кнопку и отпустил, рука еще в движении назад, а инсталлятор "мурлыкнул" и уже сообщает:
    Извините, пожалуйста!
    Но процесс инсталляции ОС,
    уже успешно ЗАКОНЧЕН!
    У супер чайников, конечно будет или шок или непонимание, но это их траблы. Больше шока!

    Есть еще позитив- это массовая запись (пачками) всех воткнутых USB флешек! Картридеры и т.п. (Моя личностная вероятность сего на сейчас около 80%)

    4. предлагаю активно ратующим за развитие проекта, особенно ядра и желающим допилить ядро (вернее сказать просто добавить) вещи связанные с дозагрузкой файлов ОСи (например, начиная от некого CFG файла конфигурации вместо синего экрана, заканчивая дровами, либами...) из каталога ОСи (или ее подкаталогов)!
    Мои BPB при прыжке в голову ядра передают в регистрах следующее

    Code: Select all

                    mov     edx, NameBootDrv    ;тип загрузочного диска
                    mov     ebx, TypeFS         ;EBX = символьный тип файловой системы этого диска
                    movzx   eax,[DirNumCluster] ;EAX = номер первого кластера оглавления каталога ОС
                       RETF   
    Рассчитываю, что появится желающий дополнить это направление (хотите как концепт принимайте) собственно модулем ДОЗАГРУЗКИ в ядре (или такой возможностью при сборе ядра), поскольку все 3 кодинга возникающие из п.1 в этом концепте, я "не закрою" ни по времени ни по возможности.
    Вообще это как бы смысловое логичное продолжение п.1., а задачу именно загрузка ядра "в 3-х экземплярах" :lol: я как бы гарантировать могу.
    В целом с Вас, уважаемый ALL, лишь третья часть именуемая: "Дозагрузка ядром (файлом) kernel.mnt необходимых файлов" или типа "Kernel System Loader".

    5. Отношение к вышесказанному должно быть пока у ALL, как ананс. Не более.
    Думаю ТС (XVilka) в некоторм недалёком будующем скоро практически поюзает, так сказать на правах заказчика.
    Некоторые пункты, освещены тут, что и XVilka про них не знает в принципе, т.к. родились по ходу :D
    XVilka, в принципе это все я сначала хотел написать в письме лично, но вроде, как актуальность темы и практические фактические результаты и п.4 могут быть основанием сказать здесь.
    З.Ы.
    Извиняюсь, за словесное обилие!
    Впрочем, как всегда. :roll:
  • VaStaNi, вы существенно опоздали. kernel/trunk/bootloader/extended_primary_loader загружает ядро и предоставляет удобное API для загрузки файлов из различных источников: как вторичный загрузчик после виндового, загрузка с CD, загрузка с FAT1x/FAT32 в CHS и LBA-варианте. Вы о загрузке файлов явно даже не начинали думать - зачем это сваливать на ядро, вкручивая туда все возможные файловые системы ещё и для реального режима, если первичный загрузчик специфичен для файловой системы и уже вынужден загружать файлы?
    Сделаем мир лучше!
  • CleverMouse wrote:VaStaNi, вы существенно опоздали.
    Я ли опоздал? :) Вроде Ваш пост мог быть ответом ТС еще в июне?
    CleverMouse, я считаю, что Вы поспешили с выводами и не разобрались в нюансах, потому как многое не стыкуется.
    Для меня показательно обилие (как ни странно и "сегодня") постов, вопросов, проблем у людей связанных с темой про HDD (а тема, надо признать широка в своем многообразии нюансов)
    Напрягает мысль вообще то, что не все так безоблачно, что все решено, что досконально, что ЭТО запросто делается...

    viewtopic.php?f=4&t=1812

    viewtopic.php?f=4&t=1811

    и в данном состоянии вопроса по п.1 ТС считаю, что они не последние тут(!),
    если это, например, как то по другому не решить или предложить выбор или иметь возможность(и) решить свою конкретную ситуацию, хотелку...

    Повторюсь.
    Речь шла про "индивидуальные цивилизованные" BPB для HDD, как это принято в основной массе ОС.
    Причем тут Ваши доводы не пойму?
    Я за возможности человека (клиента, юзера...) в том числе и ассортимент выбора!
    Я за простоту использования, нативность....
    И вместе с тем я за надежность и унификацию, стандартизацию...
    Ваш пост, как бы говорит, что все и везде уже решено, альтернатив не надо, чудненько работает везде, все довольны, а кто не знает как и что, это его проблемы, потму как все знают "как".
    Думаю, что лично я высказывание yogev_ezra, что ниже, воспринимаю правильно.
    yogev_ezra wrote:Человек согласен дать деньги за то, чтобы кто-то написал родной загрузчик Колибри для загрузки с жёсткого диска (думаю, кроме того он хочет, чтобы это работало без рамдиска). Ты можешь написать ему этот загрузчик за деньги, можешь написать бесплатно, можешь не писать, но ты не можешь ему сказать, что пользуешься другим решением (которое он не хочет), и пусть он тоже им пользуется.
    Last edited by VaStaNi on Tue Jul 26, 2011 6:17 pm, edited 1 time in total.
  • Нет, не мог. Равно как и ваш пост не является ответом. Полноценный ответ предполагает загрузку из набора файлов на диске, а не как сейчас - одного файла kolibri.img, который несколько неудобно редактировать. Пользователи эту фичу действительно регулярно спрашивают, так что она действительно востребована. У вас про это ни слова, а без этой фичи загрузка с разнообразных носителей давно есть.
    Сделаем мир лучше!
  • Опять началось... Решения только два и они уже многократно проговаривались:
    1) оставить в RAM-диске только самое необходимое для загрузки файлов с обычного диска/раздела; при необходимости сменить формат RAMFS на более удобный в плане редактирования, скорее всего какой-либо популярный архивный формат (хотя меня и FAT12 устраивает, только чтобы образ можно было использовать усеченный); четко зафиксировать в ядре момент окончания использования RAM-диска, чтобы можно было освободить занимаемую им память (как оптимальный вариант);
    2) загружать вместе с ядром дополнительный модуль, предоставляющий файловый API защищенного режима для работы с загрузочным диском/разделом (внутренняя реализация может быть разной: работа с аппаратурой через BIOS (v86) или напрямую, "вшитый" RAM-диск).

    А то что предлагает VaStaNi (при всем моем уважении), это легко достижимая, но явно не конечная цель.

    P.S. Просьба меня не пинать, как это обычно происходит, а просто проигнорировать мой пост, если мои слова кого-то раздражают.
  • Загружать набор файлов на диске - прерогатива ОС и ее функционала, как частный случай использования ее сервиса по части поддержки дисковых операций и файловых систем. Вторичные, третичные, четверичные загрузчики избыточны и не имеют смысла в дальнейшем, это балласт, для такой ОСи.
    Ядро ОСи, умеющее дозагружаться или подгружать, это уже как бы плюсик от микроядерного построения...

    И потом, сам электроный диск (в будующем) можно и не загружать весь ведь, можно его создать пустым и наполнить "потом" или наполнить минимумом в соответствии с неким RAMDISK.CFG файлом...
    Вовсе не вижу смысла на этапе старта ОСи грузить именно ВСЕ. Игры, обои....?
    Многие хотят быть заложниками ситуации? Нет.
    Они просто идут "в сторону", кромсают лишнее и ненужное и делают транки. Оно способствует общему развитию? Думаю нет.

    "Требовать" от BPB "уровня интеллекта" по части FS, чтобы "грузить списками" и это BPB, где 353 байта занимает именно чисто программный код, например, для FAT32 (загружающий, понимающий, интерпетирующий...)???
    Это перебор.
    Но в то же время, тупая загрузка файла из корневого (только) каталога, это тоже перебор.
    И все же, с помощью этих 353 байт возможно "сделать условия" для ОСи, чтобы было лучше, проще реализовать дальнейшую ДОзагрузку необходимого.

    К этим условиям относятся:

    - размещение ОСи в отдельном каталоге корня диска

    - размещение ядра в корне каталога ОСи

    - размещение остальных файлов ОСи по целевому назначению в подкаталогах, расширению и т.д. (драйвера отдельно, тулзы отдельно, скрины отдельно, мухи отдельно...)

    - информирование (от загрузчика) запущенного ядра инфой:
    --- откуда оно загружено (диск, номер или буква);
    --- какая файловая система на этом диске(с целью применить ядром нужный драйвер, конкретной FS этого диска);
    --- номер кластера(сектора) оглавления каталога ОСи (для возможности быстрой навигации внутри своего каталога обнаружения подкаталогов и файлов в них).

    В данном случае ядру (ОСи) все карты в руки даны, все последовательно и логично, по максимуму информации обеспечено кодом бутсектора(ов) для всех 3х файловых систем.
    Унификация и однообразие подхода (решения) процесса загрузки, разворота ОС в памяти, вне зависимости от типа диска и файловых систем.
    Плюс наличие инсталлятора, простота инсталляции и замены ядра в каталоге, возможность версионно называть(переменовывать каталоги)... и т.д.
    Основные аргументы и инфу я привел.
    Есть масса плюсов, надо только взять и захотеть их увидеть.
    Оправдываться или спорить я не собираюсь.
  • То есть, вы считаете, что нужно загрузить ядро и пусть оно делает что хочет, а то, что текущее ядро хочет рамдиск и просто не загрузится вашим методом, вас не интересует. В таком случае, действительно, мой пост тоже является ответом и это уже реализовано.
    Сделаем мир лучше!
  • VaStaNi, это совсем другое дело, но по-моему все-таки лучше не тянуть в ядро драйверы всех дисков/ФС, а иметь в ядре только драйвер RAM-диска/RAMFS или загрузчик (тут уже точнее только парсер) модулей ядра плюс файл в памяти, являющийся соответственно образом RAM-диска или модулем ядра, который позволял бы догрузить систему с загрузочного диска/раздела.

    --- откуда оно загружено (диск, номер или буква);
    +1

    --- какая файловая система на этом диске(с целью применить ядром нужный драйвер, конкретной FS этого диска);
    +1, хотя я для загрузочного диска/раздела подсказки не использую - чистый autodetect - все равно проверки нужно делать, а драйверов ФС на момент детекта загружено немного, поэтому поиск подходящей ФС не так уж сложен.

    --- номер кластера(сектора) оглавления каталога ОСи (для возможности быстрой навигации внутри своего каталога обнаружения подкаталогов и файлов в них).
    ? А вот это уже интересный момент... Как я понял, ты непосредственно в первичном загрузчике системный каталог не используешь, т.к. грузишь ядро из корня, так не проще ли тогда передавать ядру имя системного каталога в чистом виде? Кстати ты имя в первичном загрузчике хранишь? Если так, то получается что при изменении имени системного каталога нужно патчить первичный загрузчик. Просто как вариант может проще пропатчить файл ядра?
  • Phantom-84

    То, что ядро не знает откуда загружен образ сейчас спасает от некоторых дыр в системной защите.
  • CleverMouse wrote:...и это уже реализовано.
    Во-во. Может только чуть-чуть "унификации" добавить и все.
  • Asper wrote:То, что ядро не знает откуда загружен образ сейчас спасает от некоторых дыр в системной защите.
    Все равно все тайное когда-нибудь становится явным. Не, новых дыр мне не надо :D А вообще я не понял, зачем системе защищаться от собственного ядра.
  • http://redmine.kolibrios.org/projects/k ... Loader.txt :

    Code: Select all

    ax идентифицирует устройство:
    	al = тип:
    		'f' - флопик
    		'h' - HDD
    		'c' - CD/DVD
    		'u' - USB флешка
    		'?' - неизвестное устройство
    	ah = номер устройства (среди всех устройств фиксированного типа)
    	bx = тип файловой системы:
    		'12' = FAT12
    		'16' = FAT16
    		'32' = FAT32
    		'nt' = NTFS
    		'is' = ISO-9660
    	ds:si = far-указатель на callback-сервис
    Куда уж унифицированнее...
    Сделаем мир лучше!
  • Who is online

    Users browsing this forum: No registered users and 3 guests