Hello Артём,

Saturday, February 7, 2004, 1:59:53 PM, you wrote:

>>АБ> Что вы понимаете под словами "нормальное микроядро"?
>>То, что из имеющихся ныне операционных систем на основе микроядра, ни
>>одна не конкурирует с такими операционными системами как Linux, BSD,
>>Solaris и др. Может быть слишком самоуверенное заявление...

АБ> Возможно, но, согласен, что только открытое ПО может быть "нормальным".
Б> Windows, да и Lindows туда не тянут.
A Mach 3.0 и Hurd - это самые что ни на есть открытые разработки, при
этом - микроядра...

>>Поэтому все и будут создавать дистрибутивы на основе нового микроядра,
>>воплощая новые информационные решения.

АБ> Еще раз определимся, что такое ядро.
> <...>

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

АБ> Вряд ли мы сможем сделать какой-то прорыв в алгоритмической реализации
АБ> ядра.
Да ну... Конечно, не понятно ударение в фразе то ли на "мы сможем", то
ли "сделать какой-то прорыв". И если первое действительно "вряд ли",
то второе очень даже возможно.

АБ> То есть, если сейчас ядро напрямую не
АБ> поддерживает многозадачность (параллелизм), не поддерживает механизм
АБ> исключений, не поддерживает распределение памяти с автоматической
АБ> проверкой результата, не поддерживает классы, не поддерживает
АБ> автоматический контроль диапазона чисел, а делает все это только
АБ> посредством дополнительных, специально написанных функций, то можно все
АБ> это одновременно и элегантно получить, переписав его на языке
АБ> программирования Ada95.
Почему именно на Ada95?

АБ> Просто берем и реализуем на Ada те части,
АБ> которые раньше были сделаны на Cи, но очень некрасиво и нелогично (как
АБ> вспомогатальные функции).
Особено весело становится тогда, когда представляешь 5.5 млн. строк
кода, из которых надо выбрать те места, которые некрасиво написаны на
Cи, и их красиво переписать на Ada.

АБ> Многозадачность встроена в Ada, так что
АБ> специально делать ничего не надо, проверка диапазона и проверка памяти
АБ> тоже, исключения есть, классы тоже. Вот с этого и начать, что уже есть.
АБ> Сделать костяк на Ada, который можно назвать Microkernel.
На самом деле написание добротной архитектуры микроядра отнюдь не
тривиальная задача. ...даже на Ada...

АБ> Кто-то здесь хвалился, что может и имеет возможность переводить
АБ> документацию с английского. Так вот, лучше бы перевести руководство по
АБ> языку Ada95 на русский, т.к. такового (да и нормальных книжек) еще пока
АБ> нет. Это была бы неоценимая польза для русскоязычного ПО.
Кстати, хороший вопрос. А документация по Ada где-нибудь вообще
есть(на любом языке)? И можно ли почитать?

АБ> Далее. Если ядро было бы на языке Ada95, то интерфейс ядра можно было бы

АБ> сделать "адовский", что побуждало бы разработчиков ПО с целью наибольшей

АБ> эффективности создавать новое ПО на языке Ada.

АБ> Создана же целая ОС - AdaOS.
И как, пишут под AdaOS ПО?

>>АБ> Это не так сложно, как кажется. Конечно, есть разные принципы
>>АБ> разработки. Есть одно, другое, третье. Но, скажите, разве нельзя,
>>АБ> скажем, обойтись двумя графическими интерфейсами?

>Нет нельзя. Уже не получится...

АБ> Почему?
:)) Существует множество пользователей и разработчиков привыкших к
нескольким графическим интерфейсам. Поэтому это вызовет праведное
негодование тех, чей любимый интерфейс не будет использоваться дальше.

>>Да и конкуренция порождает развитие. Или нет?

АБ> Нам надо выбрать из всего то, что достаточно для наших задач. Зачем нам
АБ> много?
Дабы породить конкуренцию. Это нормальный механизм рынка. Вопрос
"Зачем нам много?" ведет к уменьшению роли обратной связи в разработке
программного обеспечения. В конечном итоге, мы можем получить
разомкнутую систему регулирования, выражаясь в терминах ТАУ, а это
ведет к уменьшению точности управляемого параметра. :))

АБ> Если, скажем, QT есть, то он, конечно, красив. Но ведь
АБ> возможности gtk ничуть не меньше. А QT ведь не распространяется по GPL.
А BSD тоже не распространяются под GPL. И всеми любиый Apache не
распространияется под GPL. И при этом никто и не подумает назвать эти
продукты несвободными. Это просто другое понимание свободы.
Использование или неиспользование GPL далеко не повод выносить оценку
проектам. Imho это не лучшая политика сообщества FSF, при всем моем
уважении к Столману...

>>Как сказал бы дюдюшка
>>Билл: разве нельзя обойтись двымя операционками, например, XP и Server
>>2003?

АБ> Да, он бы явно забыл о Linux... Но ведь gtk и tk мультиплатформенные!
АБ> Разрабатывай для любой ОС!
На самом деле смысл был другой: кому-то нравится один инструмент,
кому-то другой, и таких инструментов десять-двадцать, то это далеко не
повод отбирать у всех привычные инструменты, чтобы сократить число
оных до двух-трех, ибо "зачем нам больше".
Если инструмент создан, но не используется - он сам умрет, но если он
используется, значит - он нужен. Простая логика.

>>АБ> Один для компилируемых
>>АБ> языков, второй - для интерпретируемых. Например, gtk2 и tk?
>>И как ты собираешься это делать? Точнее какими способами?

АБ> Дать рекомендации писать только для этих GUI (а если кому-то эти GUI не
АБ> понравятся - предложить их улучшить), включать в дистрибутив по
АБ> возможности "правильные" интерфейсы.
Данная проблема решалась проще. Когда нексолько компаний (Digital, HP,
IBM и другие, сейчас не вспомню) объединились в Open Software
Foundation(OSF). И основной целью OSF стала разработка ОС, которая
могла составить конкуренцию разрабатывающейся в то же время SunOS
(на основе SVR4), и в то же время была свободна от лизензионных
ограничений AT&T. OSF распространила среди своих членов "Запрос на
технологии"(в оригинале, могу ошибится, "Request for Technology") и
выбрала из полученных технологий лучшие по ряду параметров. Кстати
сказать, после этого OSF выпустила небезизвестный Motif, а потом уже
OSF/1.

АБ> Да, про Assembler забыл. Но он используется редко (только для ядра и
АБ> утилит). Мы же говорим больше про приложения. И еще ошибка: PHP - не
АБ> универсальный язык.
Assembler не заменим и для прошивки микроконтроллеров, ПЗУ и вообще
аппаратных средств.
Но все равно набор языков достаточно спорен...

АБ> В России должен был властвовать царь. Но теперь, в силу исторических и
АБ> др. причин, сложно сказать какой из политических режимов лучше. Конечно,

АБ> в идеале, единоличная власть одного человека.

Ваши идеи, батенька, как в политике, так и в программировании очень
спорны.

>>Т.е. ты хочешь реализовать подобную схему: (а) собирается ядро и
>>минимально необходимый набор приложений, т.е. даже еще без X Window
>>System,

АБ> Ну, собраны они должны быть еще разработчиком дистрибутива, хотя,
АБ> впрочем, одним из заключительных этапов установки можно предусмотреть
АБ> самосбор всех используемых пакетов. А установка уже графическая! Если
АБ> пользователь не поставит XWindows - пусть не ставит, но предупреждение
АБ> об неустановленной графической среде будет выведено.

АБ> А чем .deb .rpm xfs или NTFS лучше? И какое название является, например,

АБ> более удобочитаемым?
Из вышеперечисленых - deb. :))
А что касаемо названия, тот же нелюбимый тобой Debian запоминается
лучше, нежели FTS. Попробуй кому-нибудь сказать FTSLinux, и через день
спросить "как я сказал?", я уверен 9 из 10 или не ответят, или
ошибутся. Но, в принципе, не так уж это и влияет на работоспособность
системы... Кстати, а что ж оно означает? Или это просто ты словарь в
призвольных местах открывал - вот и получилось...

АБ> Но вот кто-то хотел привести описание sysinstall.
Забей... это я так брякнул... немножко другое имел ввиду...

АБ> Еще
АБ> функция: иногда демон отслеживает (с помощью find) давно неиспользуемые
АБ> файлы пакета и предлагает и удалить.
А если я дату на год вперед случайно отодвинул, он мне и ядро
предложит удалить? Незнаю-незнаю подобная функция не очень-то и
полезна. Сильно раздражать будет.

>>А как будет с реализацией подобной схемы?

АБ> Еще пока неясно. А какие могут быть проблемы?
Я спрашивал не про проблемы, а про идеи реализации...
Не принимай уж сразу все так в штыки.

On Wed, Feb 04, 2004 at 03:32:21PM +0300, Kolotov Alexandr wrote:
> >>а кто против? Кировчане, кто может поспособствовать?
> АСГ> Теоретически могу.
> серьезно? давай проработаем эту тему...

а куды закачивать то? это я к тому, что у меня скорость по России
сильно варьируется, сначала надо замерить как быстро работает.

> >>блин, еще бы сам сайт кто-нить, наконец, замутил...
> АСГ> Во во, главное замутить, а уж с хостингом можно и договориться, это же
> АСГ> небольшой трафик
> как направление в каком мыслить (мутили я и DiMoN):
> http://www.kirov.ru/~mypost/lindocs/example/

вы мутите, мутите... если будет контент, то метров 50
под сайт дадут. Место хорошее, канал быстрый и стабильный.
Площадка физически в Москве, прямое подключение к M9, DNS, MySQL
и PHP есть, про остальное не знаю. Канал более 2Мбит.
Сервак - 2-x процессорный спарк, под gentoo linux.

Это вкратце.

ЗЫ про 500 мегов доков, пока не заикался. Скажу только, что на
том разделе, где расположены хостящиеся сайты месяц назад было
свободно 25 Гб.

ЗЗЫ Debian testing именно там качали...

On Fri, Feb 06, 2004 at 07:22:30PM +0300, Артём Бельтюгов wrote:
> >>Посмотри play.sh. Я могу посмотреть, побегать, почитать и тут
> >>же поставить,
> >>все каталогизировано и т.д. и т.п., а что ты можешь понять по
> >>названию пакета
> >>в файловом менеджере?
> >>
> По названию пакета, верно, я понять много не могу, но если этот пакет
> лежит, например, в каталоге office/printing/cups или, например, в
> programming/java/jplot, да еще с ним вместе лежит и документация, да еще
> и скриншоты, то уже многое проясняется и без установки пакета.

а поставить оттуда с соблюдением всех зависимостей? а увидеть
зависимости пакета?

> >Блин сукс, опять забыл про то, что subscribe не пропускает вложения, вот этот
> >paly.sh...
> >
> А что это за двоичный код? Не вирус ли? :)

боишься, да!!! :-) запусти и увидишь. Колотов не даст соврать,
что это не виряк, да к тому же он уже оценил возможности этой, с
позволения сказать, "технологии" :-)

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

Konstantin A. Shchekotoff wrote:

>Доброго времени суток.
>
>В Втр, 03.02.2004, в 21:12, Артём Бельтюгов пишет:
>
>
>
>>>А клепание дистров -- его предсмертная агония ;)
>>>
>>>
>
>
>
>>Как раз наоборот - его развитие... Принцип рынка: чем больше продавцов,
>>тем лучше товар.
>>
>>
>
>:) Во! Рынок вспомнили... ;) А что там у нас коммерческое?
>
Каждый дистрибутив хочет выделиться из остальных. Вам ведь не хотелось
бы, чтобы ваше детище было забыто. Поэтому один у другого перенимают
передовые решения, чтобы остаться на плову. Например, как apt-get
перешел в Red Hat-основанные дистрибутивы. К тому же, многие
разработчики дистрибутивов Linux обильно спонсируются.

>>В солидных фирмах тратятся миллионы долларов только на
>>составление спецификации для программного продукта. Продумывается все,
>>вплоть до мельчайших деталей. А уж потом наступает этап реализации.
>>
>>
>
>Правильно. Но, простите, каким местом это относится к Линуксу? ;)
>
>
Таким, что надо с головой подходить к процессу кодирования программы, а
не, простите, задним местом. Мы не будем просчитывать все до мельчайших
деталей. Но что-то ведь надо предусматривать. Не надо быть консерватором
и делать только то, чему учили, или что для нас быстрее. Надо быть
чуточку впереди.

>
>
>>Надо именно
>>ввести в среду Open-Source программистов определенные критерии,
>>определенные требования к качеству результирующего кода и его
>>сопровождению.
>>
>>
>
>Хммм...
>Умоляю, не надо никуда ничего "вводить" ;)
>
>
Да?? А зачем тогда в Debian разделение на стабильные пакеты и
нестабильные? Зачем нужны bugzill'ы? Зачем нужна определенная, и, надо
отметить, сложная политика администрирования и создания пакетов Debian?
Для унификации, уменьшения вероятности ошибок и повышения надежности. А
вы: кодируйте, как умеете. Конечно, никто не запрещает вам так делать.
Но ваш продукт, если он создан бессистемно и недокументирован, потребует
во много раз больше времени на отладку, сопровождение и возможную
модификацию. Надо думать и о других, а не только о том, как мне быстрее
создать программу.

>
>
>>Пока мы будем бессистемно "клепать" код, то так и
>>останемся с глюками и нереализованными возможностями. А документация не
>>есть второстепенное. Вспомните хотя бы наши ГОСТы на программное
>>обеспечение. У них, за рубежом, - да. Нужно быстрее создать код. Нам же
>>торопиться некуда. Можно делать на совесть.
>>
>>
>
>[поскипано]
>
>много спорного в Ваших высказываниях.
>
>2Moderator: закройте тему, во избежание ;)
>
>
>
Как хотите... Linux - не игрушка: что хочу, то и творю. Он должен быть
воплощением передовых решений и определенных стандартов, а не, как
правильно выразился раньше А.Колотов, "курсовой работой по
программированию".

-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.kirovlug-list@subscribe.ru
Отписаться: mailto:comp.soft.linux.kirovlug--unsub@subscribe.ru

http://subscribe.ru/ mailto:ask@subscribe.ru

Zmei wrote:

>Hello Артём,
>
>Wednesday, February 4, 2004, 6:26:24 PM, you wrote:
>
>
>
>>>АБ> Я думаю, к тому времени Linux будет ничуть не сложнее, а местами
>>>АБ> даже существенно легче, чем Windows.
>>>К тому времени - эт когда? Доживем ли?
>>>
>>>
>
>АБ> Это и от нас зависит. Назвался линуксоидом - полезай в Linux. Создание
>АБ> дистрибутива - великолепный способ глубоко ознакомиться с Linux. Пусть
>АБ> даже этот дистрибутив и окажется "внутреннего пользования", т.е. никогда
>
>АБ> не вышедшим в свет. Зато своя ОС будет настроена как надо, и другим
>АБ> можно рекомендации и программы дать. Если вам не нравится "новый
>АБ> дистрибутив", можно назвать его "виртуальным".
>Может быть в таком случае написать HOW_TO "Как собрать с нуля Linux с
>набором приложений?"
>
Зачем с нуля? Что, мало программ? Надо просто модифицировать!

> - во-первых, пользы для рядового, и даже
>продвинутого линуксоида будет, наверное, больше
>
Больше чем что? У нас не праздный интерес (типа абстрактной ОС "с
нуля"), а вполне практические цели, которые, понятно, надо
реализовывать, при минимуме человеко-дней.

> (я бы с большим
>удовольствиекм разобрался как собрать операционку "с нуля"),
>
Опять же наше хобби не в простом удовольствии что-то сделать. Здесь на
форуме уже звучала фраза: "работа ради работы", что сюда и применимо.
Надо делать то, от чего будет реальная польза, а не изобретать один и
тот же велосипед дважды.

>
>
>>>А если доживем, то не будет ли
>>>Linux к тому времени не более чем suxxx? Может уже через пару-тройку
>>>лет кто-нибудь напишет нормальное микроядро и все будут клепать
>>>дистрибы под энный-NIX.
>>>
>>>
>
>АБ> Что вы понимаете под словами "нормальное микроядро"?
>То, что из имеющихся ныне операционных систем на основе микроядра, ни
>одна не конкурирует с такими операционными системами как Linux, BSD,
>Solaris и др. Может быть слишком самоуверенное заявление...
>
>
Возможно, но, согласен, что только открытое ПО может быть "нормальным".
Windows, да и Lindows туда не тянут.

>АБ> Что значит - "клепать"? Создать дистрибутив - не реку перейти. Создают
>АБ> не от хорошей жизни. Новый дистрибутив является воплощением новых
>АБ> информационных решений.
>Поэтому все и будут создавать дистрибутивы на основе нового микроядра,
>воплощая новые информационные решения.
>
>
Еще раз определимся, что такое ядро. Это набор базовых программ,
аналогичных в чем-то BIOS, для поддержки самых важных и одновременно
общих возможностей работы на компьютере: тест и автоопределение
оборудования системы, поддержка работы с памятью и виртуальными
страницами, поддержка различного оборудования (через драйверы),
многозадачности, загрузки и др. Даже если ядро имеет модульную
структуру, эти модули являются не чем иным, как просто драйверами. И они
жестко привязаны к функциям ядра, так что, например, если вы сменили сам
образ ядра, а модули оставили прежними, то в общем случае такое не
пройдет. Поэтому если вы на компьютере просто загрузите одно ядро, то
работать вы не сможете, так как необходимы еще вспомогательные
программы, которые через функции ядра осуществляют взаимодействие с
внешним миром, как-то: с устройствами, с пользователем. Ядро себе можно
представить как библиотеку, которая автоматически загружается при
старте, но которая содержит лишь функции, которые должны быть кем-то
использованы. И именно за счет того, что ядро представляет своеобразный
интерфейс (как бы в Cи выразились - прототип) для приложений, а сама
реализация ядра скрыта от приложений, то это и позволяет модернизировать
ядро, не опасаясь, что другие программы не будут работать. С этой точки
зрения разработка нового ядра есть крайне сложная и ответственная
работа. Точно так же, как и, например, разработка библиотеки libc.
Конечно, кроме ядра часть их функций могут выполнять и утилиты, но они
реализуют в большей мере сервисные функции, не являющиеся обязательными.

Вряд ли мы сможем сделать какой-то прорыв в алгоритмической реализации
ядра. Впрочем, если подумать, можно улучшить работу менеджера памяти или
изменить алгоритм многозадачности; можно, например, сделать, чтобы
пользователь мог задавать разные алгоритмы их работы вручную, если
что-то не устраивает. Так можно повысить быстродействие.
Вообще, только в последнее время заговорили об оптимизации работы в
Linux. Однако и здесь часто упускают такие важнейшие оптимизации, как
минимум занимаемого места в ОЗУ или на диске, меньшая загрузка
процессора, ссылаясь на то, что всегда можно купить процессор, память
или винчестер помощнее. Но это тупиковый путь. Программа не должна
поглощать память лишь только потому, что она сложная и многие не
задействованные части просто лежат на винчестере или в памяти.

Но вот в программной реализации ядра сделать прорыв можно, опираясь даже
на существующий алгоритм ядра. То есть, если сейчас ядро напрямую не
поддерживает многозадачность (параллелизм), не поддерживает механизм
исключений, не поддерживает распределение памяти с автоматической
проверкой результата, не поддерживает классы, не поддерживает
автоматический контроль диапазона чисел, а делает все это только
посредством дополнительных, специально написанных функций, то можно все
это одновременно и элегантно получить, переписав его на языке
программирования Ada95. Я не думаю, что это так уж и сложно сделать.
Если написать нормальный конвертер из С в Ada, то с помощью него можно
выполнить большую часть работы. Конечно, как правильно заметил А.
Колотов, ядро, возможно, пишется с использованием нестандартных
подходов. Но если так разбираться, то и в любой программе могут быть эти
самые нестандартные подходы. Конечно, в ядре их может быть больше. Можно
ведь создать конвертет с запросом от пользователя в особо сложных
случаях. А можно и без запросов. Есть же gcc, который умеет
оптимизировать и нестандартные подходы. В принципе, для начала можно
даже и не с конвертером. Просто берем и реализуем на Ada те части,
которые раньше были сделаны на Cи, но очень некрасиво и нелогично (как
вспомогатальные функции). Многозадачность встроена в Ada, так что
специально делать ничего не надо, проверка диапазона и проверка памяти
тоже, исключения есть, классы тоже. Вот с этого и начать, что уже есть.
Сделать костяк на Ada, который можно назвать Microkernel. А остальное
можно оставить пока и на Cи (хотя, конечно, без поддержки новых
возможностей типа исключений или проверки на диапазон), т.к. в Ada
имеется интерфейс c Си. Со временем конвертером или вручную можно
постепенно переводить оставшуюся часть кода. Не так ее и много без
модулей (вспомните - не влезает ли образ ядра на дискету?).

Кто-то здесь хвалился, что может и имеет возможность переводить
документацию с английского. Так вот, лучше бы перевести руководство по
языку Ada95 на русский, т.к. такового (да и нормальных книжек) еще пока
нет. Это была бы неоценимая польза для русскоязычного ПО.

Далее. Если ядро было бы на языке Ada95, то интерфейс ядра можно было бы
сделать "адовский", что побуждало бы разработчиков ПО с целью наибольшей
эффективности создавать новое ПО на языке Ada. Создана же целая ОС - AdaOS.

>АБ> Это не так сложно, как кажется. Конечно, есть разные принципы
>АБ> разработки. Есть одно, другое, третье. Но, скажите, разве нельзя,
>АБ> скажем, обойтись двумя графическими интерфейсами?
>Нет нельзя. Уже не получится...
>
Почему?

>Да и конкуренция порождает развитие. Или нет?
>
Нам надо выбрать из всего то, что достаточно для наших задач. Зачем нам
много? Если, скажем, QT есть, то он, конечно, красив. Но ведь
возможности gtk ничуть не меньше. А QT ведь не распространяется по GPL.

>Как сказал бы дюдюшка
>Билл: разве нельзя обойтись двымя операционками, например, XP и Server
>2003?
>
Да, он бы явно забыл о Linux... Но ведь gtk и tk мультиплатформенные!
Разрабатывай для любой ОС!

>Кто за две операционки на рынке - поднимите руки.
>
Чем меньше, тем лучше. Лишь бы нас удовлетворяло. Понять не могу, почему
все хотят чего-то многого? Так говорили и про gcc. Что он так много взял
на себя, что создает приложения и для разных платформ, и что поэтому он
не может, якобы, конкурировать со специализированными компиляторами для
конкретных платформ. Ан, может. Еще как может! А если, скажем, чего-то
еще пока нет в gtk, что есть в QT (например, внешней красоты), то это
еще не повод держать эти библиотеки обе. Со временем это будет и в gtk,
а метаться туда-сюда: унификации никакой, форматы не совпадают. Что все
время тратить только на создание конвертеров? Не зря же Минобороны США
обобщило ок. 400 языков программирования и их диалектов и взамен всем им
решило создать свой, универсальный, для собственных нужд. Он назвался
языком Ada(83)...

>АБ> Один для компилируемых
>АБ> языков, второй - для интерпретируемых. Например, gtk2 и tk?
>И как ты собираешься это делать? Точнее какими способами?
>
Дать рекомендации писать только для этих GUI (а если кому-то эти GUI не
понравятся - предложить их улучшить), включать в дистрибутив по
возможности "правильные" интерфейсы.

>
>АБ> И нельзя
>АБ> разве обучить людей всего 5 универсальным языкам программирования на все
>
>АБ> случаи жизни: Ada95, Perl, Python, Java, PHP?
>АБ> Можно.
>Нет, нельзя... Во-первых, те же причины, что и выше. Во-вторых, вы,
>уважаемый, явно забыли Ассемблер... Даже правильей сказать -
>Ассемблеры.
>
Да, про Assembler забыл. Но он используется редко (только для ядра и
утилит). Мы же говорим больше про приложения. И еще ошибка: PHP - не
универсальный язык.

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

>
>
>>>Чтобы создать унифицированную среду надо
>>>прежде всего, наверно, убрать из механизма установки ОС установку
>>>всяких программ и утилит:
>>>
>>>
>АБ> Верно. Идея, в принципе, как в Debian: т.наз. базовая система. Но там
>АБ> базовая система слишком разросшаяся. Зачем необходимы сетевые
>АБ> приложения, если я, например, не собираюсь пользоваться сетью? И вообще

>АБ> эти 90, а то и более Мбайт можно урезать. Речь уже об этом как-то шла на
>
>АБ> usenet vyatka.uuug.
>Т.е. ты хочешь реализовать подобную схему: (а) собирается ядро и
>минимально необходимый набор приложений, т.е. даже еще без X Window
>System,
>
Ну, собраны они должны быть еще разработчиком дистрибутива, хотя,
впрочем, одним из заключительных этапов установки можно предусмотреть
самосбор всех используемых пакетов. А установка уже графическая! Если
пользователь не поставит XWindows - пусть не ставит, но предупреждение
об неустановленной графической среде будет выведено.

> (б) среди которых присутствует система управления пакетами,
>скажем fts (кстати что такое fts? не буду уж говорить, что
>неудобочитаемое название);
>
А чем .deb .rpm xfs или NTFS лучше? И какое название является, например,
более удобочитаемым?

>(в) начиная с первого запуска системы можно
>грузить данную утилитку и устанавливать любые приложения в любом
>составе компонентов;
>
утилитку можно и грузить по требованию, но она будет вызываться и
специальным демоном.

> (г) с помощью этой же утилиты удалять любые
>приложения или любые компоненты из уже установленных приложений;
>
Почти что любые. Критически опасные (для работоспособности системы)
файлы удалить не получится.

> (д) с
>помощью демона отслеживать все обращения к компонентам пакета, которых
>нет в системе и устанавливать их... может еще какие-либо функции.
>Что ж... может получится и интересно. Во всяком случае достаточно
>новый подход.
>
Я тоже так думаю. Но вот кто-то хотел привести описание sysinstall. Еще
функция: иногда демон отслеживает (с помощью find) давно неиспользуемые
файлы пакета и предлагает и удалить.

>
>А как будет с реализацией подобной схемы?
>
Еще пока неясно. А какие могут быть проблемы?

>
>
>
>>>...Куда ведет дорога, вымощенная благими намерениями?
>>>
>>>
>
>АБ> И куда?
>
>В ад...
>
>
>
Общераспространенное заблуждение. Только из благих намерений выглядывает
истина. Конечно, если эти намерения остаются таковыми и никто более не
тревожит эти намерения.

>
>
>>>АБ> Жаль только, что все почему-то пока только критикуют, а как коснется
>>>АБ> реальной пользы, то сразу в кусты... Ведь, по существу, чем отличается,
>>>АБ> скажем, Debian от RedHat, а RedHat от ASPLinux? Всякими наворотами,
>>>АБ> удобствами и пр. А ведь суть одна. Берут же одни и те же исходники с
>>>АБ> сайтов их авторов. Только вот политика администрирования этих пакетов

>>>АБ> несколько отличается. Вот и получился новый дистрибутив. Все равно же

>>>АБ> Linux.
>>>А может направить знания и энергию в другое русло?
>>>
>>>
>
>АБ> Например? Недоверием и предвзяточничеством всегда рушатся перспективные

>АБ> проекты. Всегда (особенно в отсталых городах типа Кирова) так и говорят:
>
>АБ> да ну, зачем это вам, бросьте: все равно ведь себя или начальника не
>АБ> перепрыгните.
>Ни в коем случае. Но в споре рождается истина. Вот сейчас начал
>объяснять поподробнее - вроде бы и есть в этом что-то...
>
>
>
Наверное есть...

>
>
>
>>>АБ> Я уже не говорю о возможности призыва к разработчикам ядра (и
>>>АБ> многих других программ под Linux) переписать его на Ada95 (или хотя бы
>>>
>>>
>
>
>
>>>АБ> на C++)!
>>>З а ч е м ???
>>>
>>>
>
>АБ> Затем, чтобы избавиться от архаичности, малой функциональности, глюков и
>
>АБ> пр. и чтобы новых программистов не одурачивать.
>
>
>
>>>К тому же скоко там в линуксе строк кода? Не около 5.5 милионов?
>>>
>>>
>
>АБ> Не вручную же! Можно сделать нормальный, интеллектуальный конвертер.
>Мальчик, девочка... Какая в жопу разница?
>Факт в том, что легче начать писать на Ada другую операционку, дабы
>еще и избавится от некоторых архаичных элементов архитектуры.
>
В принципе, правильно. Но кто этим будет заниматься?

>Теоритеческая наука не стоит на месте... Да и некоторые старые теории
>не были поностью реальзованы. Вот это тогда и можно назвать прорывом.
>
>
>
Поживем - увидим...

>
>
>

-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.kirovlug-list@subscribe.ru
Отписаться: mailto:comp.soft.linux.kirovlug--unsub@subscribe.ru

http://subscribe.ru/ mailto:ask@subscribe.ru

Konstantin A. Shchekotoff wrote:

>В Чтв, 05.02.2004, в 20:21, Zmei пишет:
>
>
>>KA> Linux From Scratch или LFS? Погугли... Данное HOWTO даже есть на
>>KA> русском...
>>О данном HOWTO не слышал, так что спасибо, посмотрю-почитаю.
>>
>>А, может, тогда написать howto "Как собрать с нуля Линукс с набором
>>приложений в дистрибутив"? Или такой тоже уже есть?
>>
>>
>
>эхх. :-\
>
Вот именно. Зачем с нуля, когда и так уже много чего есть. С нуля не
осилить...

-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.kirovlug-list@subscribe.ru
Отписаться: mailto:comp.soft.linux.kirovlug--unsub@subscribe.ru

http://subscribe.ru/ mailto:ask@subscribe.ru

Вопрос.
1)Почему нельзя не воспроизводится звук сразу же из нескольких
программ в Linux? На пример запущен XMMS, то из других программ звука
не будет. Звуковуха C-media 8738.
2)Если отключить в BIOS прерывания на USB порт то при загрузке
система пишет что их нет.
Система Acorp 7KT266A/Duron 850/512 mb/32 mb GF2MX400/
ASP Linux 9 ядро 2.4.20
********
Всего хорошего, Dimon...
7 февраля 2004 г. 12:46
kds@l*****.ru
ICQ 161208463

-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.kirovlug-list@subscribe.ru
Отписаться: mailto:comp.soft.linux.kirovlug--unsub@subscribe.ru

http://subscribe.ru/ mailto:ask@subscribe.ru