Не пора ли выпустить Колибри 0.7.8.0?

Share your distros and discuss others'
  • У меня есть конструктивное предложение. Чтобы не создавать дополнительных проблем всем - можно сделать зеркало SVN и ковырять там. В обязательно порядке все подробно документируя. В этом случае никаких граблей для всех остальных разработчиков во время переделки не будет. Когда и если процесс будет доведен до логического финала - остальные разработчики смогут переключиться.

    Овцы сыты, волки целы, пастух сидит дома, пьет чай и курит мануалы...
  • Ты прав, так и сделаю.
  • maximYCH wrote: Предлагаю для каждого приложения отвести папку, так же, как это сделано в windows.
    Зачем? Для того, что бы можно было постепенно прийти к системе пакетов. Что бы стандартный менеджер знал: устанавливают софтину? добавить файлы в applications/%appname%/, добавить в список applications.list, /config/menu.list. Удалить? Сделать обратные действия. И т.д.
    Мой Debian чуть не удавился от зависти.
    По мне так удобней сделать папку /bin/ с бинарниками, папку /conf/ с конфигами и папку /share/ с ресурсами(вот тут можно отдельную папку для каждой программы). Ибо получаем одну папку со всеми программами(быстрый поиск), одну папку с конфигами(удобно при переустановки) и папку с ресурсами.
  • maximYCH
    Против изменения структуры файловой системы и именования её составляющих, а уж тем более нет смысла в менеджере пакетов, т.к.
    а) В Колибри почти все программы уже в составе дистрибутива, т.к. их не так уж и много.
    б) Программы для Колибри врядли можно назвать пакетами, они миниатюрны в соотствии с концепцией
    в) Создание системного реестра вроде бы было признано негативным явлением.

    Также не вижу смысла выпускать дистрибутив перед самым новым годом, внимание пользователей сейчас направлено на предстоящие праздники. ИМХО дистрибутив лучше выпустить, когда будет готово то, что запланировано. По крайней мере я надеюсь увидеть там драйвер HDA, возможно новый сетевой стек и побольше новых программ и усовершенствованных уже имеющихся.
    Предлагаю всем для начала выбрать для себя то, что он хотел бы видеть под своим именем в Changelog'е и взяться за интенсивную работу над этим. Помнится diamond хотел внести некоторую периодичность в выпуск дистрибутивов, так вот было бы неплохо уложится в срок до 31 января, как все знают, это дата выхода 0.7.5.0.

    P.S. Не обижайся, но мне кажется, что в качестве сборщика официального дистрибутива должен быть выбран программист имеющий значительный опыт и знания в прикладном и системном программировании для системы, а иначе будет очередной вариант на тему "iOneKolibri - Колибри от iOne (от меня и пары друзей)".
    Сборка официального дистрибутива, это не просто собрать обновлённые исходники с SVN, это большой объём работы, требующей некоторой квалификации. Вот тут всё никак процесс создания ночных сборок восстановиться не может, а это ведь значительно упрощает работу по сборке дистрибутива.
  • Я не разделяю идею перестройки дерева каталогов _сейчас_, но против "я сделаю и покажу вам, что это удобно" абсолютно ничего не имею. Не отрицаю, подобная мысль приходила и мне в голову; однако, на мой взгляд, стоило бы сперва всё обсудить, оценить плюсы/минусы существующих реализаций других ОС, сделать поправки на реалии КолибриОС. Приступать к реализации разумно, например, после следующего релиза, но только если на этом сойдётся мнение сообщества.

    И если мы сейчас на этапе обсуждения, то я, в целом, соглашусь с s1n. Разве что мне не понятен момент с конфигами: если имеется в виду аналогия с /etc для системных конфигов, то стоит добавить и что-то вроде /home для настроек пользователей (мы ведь к этому идём?), а если настройки/параметры драйвера будут лежать рядом с настройками змейки, то зачем оно такое надо?

    Asper,
    поддерживаю идею о периодичности выпуска релизов. Хотя, конечно, в моей ситуации об этом просто говорить.
  • Imho лучший вариант, когда приложение держит все свои файлы в одном каталоге. Иначе получается как в винде, приложение размазывается на 4-5 каталогов, uninstall вечно тупит, в итоге "Мои документы" и "Application Data" забиваются мусором. Про реестр лучше и не вспоминать.
  • Так было в MS-DOS, так по факту есть в большинстве случаев в Колибри.
  • Serge wrote:лучший вариант, когда приложение держит все свои файлы в одном каталоге
    Я тоже так думаю. Иначе будет не понятно какой файл от какой программы попал в папку с общими настройками. При удалении программ это создаст много трудностей. А что если имена файлов настроек в разных программах будут совпадать (например options.ini), как решать такую проблему. А так записал папку с программой и нет никаких проблем с установкой. Кроме того все настройки скидывать в одну кучу это создать слабость в системе для различного вида вирусов. Почистил папку и система вообще потеряла все свои настройки...
  • dunkaist wrote:Я не разделяю идею перестройки дерева каталогов _сейчас_
    Я тоже.

    Но перестройка дерева каталогов ИМХО нужна. Как я вижу его _сейчас_:
    Папка bin на rd1 - в ней все исполняемые программы. Зачем? Чтобы можно было запускать программы без указания каталога (из shell, например, или run). А насчёт настроек и данных приложений - в корне того же rd1 создаём папку conf (etc) или/и data. И тогда:

    1) Если conf и data: в conf - отдельные конфиги, в data - папки с данными приложений. имена конфигов и папок соответствуют именам программ.
    2) Если только data (что для мне больше нравится): в этой папке находятся папки с данными и настройками программ.

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

    Но тут возникает скользкий вопрос, о которых вроде никто не упоминал - ограничения FAT12 на количество файлов/каталогов.
  • Albom wrote: ...Но тут возникает скользкий вопрос, о которых вроде никто не упоминал - ограничения FAT12 на количество файлов/каталогов.
    FAT12/16 ограничена по размеру до 65 525 кластеров. Каждый кластер имеет фиксированный размер в зависимости от размера логического диска. Ограничения по количеству кластеров, и их размеру (32 Кбайт) приводят к общему ограничению по размеру диска (не более 2 Гбайт). Помимо этого, FAT12/16 обычно имеет ограничения по количеству файлов и папок, которые могут содержаться в корневом каталоге (в зависимости от диска максимальное значение колеблется от 200 до 400) http://www.oszone.net/466/
  • Roverman wrote: FAT12/16 ограничена по размеру до 65 525 кластеров... Ограничения по количеству кластеров, и их размеру (32 Кбайт) приводят к общему ограничению по размеру диска (не более 2 Гбайт)
    Размер кластера в Колибри не должен быть слишком большим, даже 512 байт уже приводят к заметным потерям дискового пространства (обрати внимание на средний размер файлов на рамдиске)

    Так что объем FAT1x -диска реально ограничен пределом 64к х 512 = 32Мбайт.
    Евангелие от Иоанна: стих 1

    Code: Select all

    ; В начале было Слово:
    B32:        mov     ax, os_stack       ; Selector for os
    [/size]
  • А разве на дискете (соответственно и в образе) может быть размер кластера, не равный 512 байтам? Кто-нибудь имеет информацию о потенциальных возможностях и ограничениях файловой системы дискеты? Да, у Зубкова (вроде) было описано, что есть ограничение на число файлов и каталогов в корне диска. +Кластер в 512 байт... А значит, пусть даже если конфиг будет содержать 1 байт, то занято будет все 512 (а если 513, то вообще 1024)... О вложенности каталогов никто не знает? (вроде в досе была максимальная глубина 8...)

    : Вообще, у меня была идея (только идея, реализовывать её я бы ни за что не стал), что ФС рамдиска лучше организовать в виде архива, к примеру tar. Без всякого сжатия. Итого на дискете имеем 2 файла - kernel.mnt и этот файл. Тогда, по идее, нет ограничение на 1,44 МБ. Вроде похожая реализация была в KolibriPE... Но это опять же не к текущему дистрибутиву, а вообще...
  • Albom
    http://ru.wikipedia.org/wiki/FAT
    Не путай размер кластера и размер физического сектора.

    Если не отказаться от минимального размера в 512 байт, то при максимальных 4084 доступная емкость не более 2 Мбайт.
  • maximYCH wrote:
    Под всеми видами носителей я имел ввиду:
    - Дискета
    - Винчестер
    - CD / DVD
    - USB
    - SD карточка.
    Инсталлятор вещь хорошая...
    Вопрос:
    1. Сможет ли он подготавливать эти носители (всмысле форматировать, делать их загрузочными и т.п.) ?
    2. Как быть с драйверами? После установки править ручками, или будет возможность подсунуть
    их в процессе установки, выбрав из списка? (только если установка без использования образа?)
  • Who is online

    Users browsing this forum: No registered users and 7 guests