Новости HLFS

а что это такое и с чем его едят?

а хз, вот нашел только 9.2.10 Hlfs

A file system that uses the user credentials (primarily uid and gid) to create symbolic links different for each user and group, much the way Hlfsd does [Zadok93b]. Hlfs could be used in conjunction with a cryptographic file system to provide user-specific encryption file systems.

a po linku nesud'ba sxodit'? http://lfs.osuosl.org/hlfs/whatishlfs.html

Началась ерунда. Зачем поддерживать и glibc и uClibc. "Масло маслянное". Всё из-за сумятицы в головах. Смысла в проекте ничтожно мало. До канонического uClibc buildroot/a, в котором всё есть и то, что есть - превосходно, им очень далеко. Тогда зачем? Единственное объясниние: поняли, что LFS против uClibc не выстоит и пробуют не пропасть во времени. Мой совет LFS - перенаправить свои усилия целиком на поддержку uClibc, влиться стройными рядами и сделать это, по-возможности, быстрее. Суть LFS, по-большому счёту, в документировании и тестировании, вот этого uClibc пока и не хватает...

hardened linux from scratch

Да уж, я когда увидел поддержку glibc даже глаза вначале стал протирать, затем подумал про сборку "И :)" оказалось что "или то, или то". А как же тогда -- "мы используем uClibc не потому, что она маленькая, а потому что она поддерживает ..., а glibc -- ... ". Как только gentooшники привернули в glibc PIE и PAX сразу же glibc стала хорошая. Однако, кроме этого прогресс есть -- включили gettext, хотя пока всё ещё собирается с --disable-nls. И так, кое-что по мелочи...

Это такая штука, типа extender -- в стиле "Почувствуй себя Патриком" :)

Это тоже был я, однако.

Мне одно непонятно. Если они вернулись к поддержке glibc, зачем вести два проекта. Лучше уж слить LFS и HLFS в одно целое и не плодить лишних сущностей.

> поняли, что LFS против uClibc не выстоит

Кстати, я здесь чуточку не понял, что именно Вы хотели сказать. И почему Вы перестали [писать/в/своём/стиле]? :)

HLFS (Half-Life File System)

> Суть LFS, по-большому счёту, в документировании и тестировании, вот этого uClibc пока и не хватает...

Ты чего-то перепутал или недопонял. Как раз в uClibc к тестированию
очень серьёзный подход. Вряд ли найдёшь другой такой проект, где так
широко используются автоматизированные контрольные тесты.

:) Собственно, я об этом же. Вот представьте, строили, строили всё под glibc, проблем, с которой так же было и остаётся немало, судя по постингам в подписном листе. Построили вобщем достаточно грамотную вещь, которая при желании учащегося, собирается в работающую систему и вполне способствует образовательным целям, а тут uClibc - всё тоже самое только гораздо проще и гораздо красивее. И главное, uClibc buildroot позволяет собрать работающую uClibc систему автоматически. Далее мои предположения: Тогда зачем LFS? Давайте делать LFS на uClibc... :) - HLFS. А зачем - ведь с uClibc есть buildroot. Привычки-то старые, привыкли всё на glibc. Что-то не собралось :) (хотя странно - в buildroot uClibc двойная поддержка - необходимый минимум и не только, дублируется busybox/ом, можно сказать обратное верно) , ну давайте ещё добавим glibc :). Добавили, и что получилось :) ? Вобщем пока я совсем не понял смысл этих движений... А надо было просто признать: LFS свою задачу выполнил, закрываем - давайте поможем uClibc.

>Кстати, я здесь чуточку не понял, что именно Вы хотели сказать. И почему Вы перестали [писать/в/своём/стиле]? :)

Меня построили :). http://www.linux.org.ru/view-message.jsp?msgid=710040

>> Суть LFS, по-большому счёту, в документировании и тестировании, вот этого uClibc пока и не хватает...

>Ты чего-то перепутал или недопонял.

Это вряд ли. Это ты меня, вероятно, не очень хорошо понял... Я конечно, далеко не претендую на uClibc guru :), да и нет предела совершенству, но..., поверь, с uClibc я возился достаточно.

Ты так же, как и я в uClibc подписном листе и так же, как и я каждодневно обновляешь uClibc cvs и собираешь buildroot? :) Если да, то как долго? И почему ты тогда не помогал мне здесь, когда мне одному приходилось отстаивать uClibc? :) Шучу вроде, но в каждой шутке... :)

Какие проекты ты реализовал на uClibc? Я портирвал opie - fork qtopia на х86 архитектуру, причём на uClibc. Из менее значимых вещей, могу отметить недавнюю помощь разработчикам GeeXboX в переводе документации. GeeXboX перевели на uClibc. Сейчас заручившись помощью aurel/a, который написал i810tvout под uClibc для GeeXboX, пытаюсь адаптировать i810tvout для работы с i855GME.

>Как раз в uClibc к тестированию очень серьёзный подход. Вряд ли найдёшь другой такой проект, где так широко используются автоматизированные контрольные тесты.

Спасибо за информацию. Как я понимаю, с недостаточным документированием uClibc ты спорить не будешь? :) Благо, сами разработчики постоянно указывают на это. Насколько помню, около месяца, как документированием занялись вплотную. Месяц, как появилась помощь при конфигурировании...

Признаю, что uClibc я не тестировал, насколько тебя понимаю, системой специализированных контрольных тестов. Ты должен быть в курсе, как активно обновляется uClibc. По этой причине, я пока и не пытался разобраться с uClibc тестированием. Верю разработчикам. Более того, за всё время, у меня был лишь один, относительно серьёзный, возможно(!) баг, когда я собирал buildroot для i486sx, при указании отсутствия метематического сопроцессора, о чём я писал в uClibc листе. Кстати, было исправлено. Но это долгая история...

Есть баг, например, когда указываешь не поддерживать файлы > 2GB, тогда buildroot останавливается на bzip/е, но это даже в документации к bzip указано, так мелочь... комментируй включённный по умолчанию BIGFILES=-D_FILE_OFFSET_BITS=64

Для себя не уточнял, но полагаю, что непротестированные части не выпускаются для обновления. Однако, если ты каждый день читаешь подписной лист, то можешь заметить, что находят много всего... Может быть находят по причине того, что 1. разработчики не тестируют перед обновлением, 2. тесты устаревают или не адаптируются для новых возможностей, 3. тесты плохие?

:)

Чудес не бывает и, естественно, что как не тестируй, если обновляешься постоянно, всё равно и тем более, что-то вылезет. Я писал, как раз не о том, что в uClibc плохое тестирование: >в документировании и тестировании, вот этого uClibc пока и не хватает...

Я сказал, что uClibc не хватает тестирования, понимаешь разницу. Причём - это моё мнение. Но это общее замечание. Согласись, тестирования никогда не бывает много... :).

А вобще в целом с тобой соглашусь. Стабильность uClibc чувствуется, есть изначально "кривые" вещи, но uClibc именно не "кривая".

Напиши, если не сложно, подробнее об автоматизированных контрольных тестах uClibc и их применении.

Кстати, мы с Вами уже обсуждали... :)

Ответ на: Re: GeeXboX 0.98.5 от domenick 30.12.2004 23:34:37 Re: GeeXboX 0.98.5 >> процесс станет необратимым >А что есть разве примеры обратных переходов. Lumi (*) (31.12.2004 0:36:47)

Ответ на: Re: GeeXboX 0.98.5 от Lumi 31.12.2004 0:36:47 Re: GeeXboX 0.98.5 >Я не встречал пока, но вполне можно предположить, что кто-то, вернётся к glibc, попробовав uClibc. Другой вопрос, станет ли переход на uClibc массовым и когда. domenick (*) (31.12.2004 1:19:21) Так что, если теперь из HLFS исключат uClibc :))), формально будет первый пример.

Далее: >что LFS против uClibc не выстоит

Это нечто, вроде долгосрочного прогноза. У buildroot uClibc и LFS есть много общего, что позволяет их сравнивать. А метания LFS-HLFS-uclibc проясняют ситуацию, не в пользу LFS, на мой взгляд.

> Это вряд ли. Это ты меня, вероятно, не очень хорошо понял...

Я пока ещё хорошо понимаю русский язык - и народный и технический ;)
В проекте uClibc очень хорошо с тестированием. По крайней мере с
тестированием на соответствие стандартам. Они стандартно используют
NIST-PCTS тесты: http://www.itl.nist.gov/div897/ctg/posix_form.htm
Может потому и ошибки всё ещё находят? ;)

> И почему ты тогда не помогал мне здесь, когда мне одному приходилось отстаивать uClibc? :)

А я не фанат-с... Увы. С проектом знаком неплохо, и использовал кое-где.
Точно так же и с dietlibc работал и с другой экзотикой. Да и к тому же
нехватает пока некоторых мелочей. Мне nls нужен рабочий однозначно.

> Так что, если теперь из HLFS исключат uClibc :))), > формально будет первый пример

Повода для :))) я не вижу. На мой взгляд первейшая задача сейчас это (анонимус выше очень прав) качественная поддержка родных языков -- это поможет не отпугнуть от HLFS потенциальных пользователей, так как многие сейчас занимаются Linux (в том числе и *LFS) либо ради любопытства, либо ради обучения. Те кто пользуют buildroot -- делают это весьма сознательно, для своих специфических задач (типа GeeXboX), таких ничем не отпугнёшь.

По ссылке:

> Мы могли бы избавиться от половины символов разного рода на клавиатурах и в шрифтах без потери в чём либо.

Как бы мы тогда программировали на жемчуге? :)))

А в общем я рад, что Вы закончили лингвистические опыты на ЛОРовцах.

>А я не фанат-с... Увы.

:) Немного странно, но после этой фразы, я понял, что, видимо, стал фанатом uClibc :).

>Точно так же и с dietlibc работал и с другой экзотикой.

Это, безусловно, ценно.

>Мне nls нужен рабочий однозначно.

А что, разве в uClibc она не рабочая? Дело в том, что мне это пока не нужно было и я не разбирался особо с поддержкой nls в uClibc. Согревало душу :) , что всё больше в uClibc встречается вещей, относящихся к nls.

>качественная поддержка родных языков -- это поможет не отпугнуть от HLFS потенциальных пользователей,

Пока всё же предположу, основываясь на косвенных признаках, что в uClibc c этим всё нормально. Будет время, проверю лично :). uClibc-locale довольно давно присутствует в buildroot.

>Как бы мы тогда программировали на жемчуге? :)))

Как угодно, лишь бы не на пхп :) Пока такое мнение. И вобще, перл тоже знаете ли..., кхм :). Нужен, uPerl :). Вобще, если Вы знаете perl хорошо, это бы здорово помогло. Дело в том, что я предложил unsaid/у попробовать развить проект, который очень поверхностно может быть охарактеризован, как ос для носимых компьютеров на основе uClibc. Вот пока думаем, какой перловый форум лучше. Может посоветете чего? А то и поучавствуете? :)

>А в общем я рад, что Вы закончили лингвистические опыты на ЛОРовцах.

:) Простейший пример, вот одно и то же меню с/без заглавных букв, горизонтальное:

Адрес Правка Вид

адрес правка вид



вертикальное:

Адрес
Правка
Вид

адрес
правка
вид

Вот минималистский подход в действии, это касается не только uClibc. А эти перескоки с "А" на "д", с "П" на "р" и т.д. - совершенно не гармонично. Пространство за "А" и далее над словом пропадает. Более того, если быть последовательным и начинать каждое предложение с заглавной буквы, то в конце предложения надо ставить точку. А именно:

Адрес.
Правка.
Вид.

Почему же в обычном меню нет точек, где страшные крики по этому поводу? ... :) Закроем глаза и сделаем вид, что ничего не происходит? :)

Так что мы ещё поборемся... :)

>и не плодить лишних сущностей.

Вот Вы сами, вероятно, сторонник этого. Я бы уточнил:

>Известное философское положение, получившее название ?бритвы Оккама?, или ?принципа бережливости Оккама?, по имени английского схоластика У. Оккама. Принцип сформулирован им в словах: ?Сущности не должны быть умножаемы сверх необходимости? (Entia non sunt multiplicanda praeter necessitatem). Оккам формулировал этот принцип во многих своих сочинениях, например Philosophia naturalis, Roma, 1637.

Принцип бережливости - золотые слова... Применительно к информационным технологиям - в том числе и баги, следствие, непонимания и не следования, указанному принципу.

Придёт время 3d стереоинтерфейсов, определяемых системами формирования изображения для каждого глаза (для тех, у кого их не меньше двух, по крайней мере :) ). Ура, товарищи... :). Для таких интерфейсов лаконичность и отсутствие лишних сущностей будет определяющим. Интерфейс не должен отвлекать возможностью изменить картинку фона, например. Интерфейс должен концентрировать пользователя системы управления на выполнении задачи, причём возможно быстром выполнении, особенно в быстро меняющихся условиях... и уж тем более, не транжирить ресурсы, которых некогда не бывает много, для обслуживания лишних сущностей. Вы знакомы с теорией, которая рассматривает человека, как фактор, могущий являтся препятствием увеличению энтропии...? :)

Я вот сейчас подумал, хороший девиз для предложенной ос - рос:

>Entia non sunt multiplicanda praeter necessitatem

William Occam

Немного не о HLFS. Как-то в прошлом или позапрошлом месяце здесь пробегали новости и о LFS и о HLFS. В тех форумах я предлагал выложить свои скриптики для автосборки LFS. Никто не предложил общедоступного места. Тогда я на прошедших праздниках проверил их и открыл страничку http://kaminsky.pochta.ru. Это мой первый опыт в интернет-дизайне, поэтому прошу ногами не пинать. Судя по всему, мои скрипты можно легко адаптировать и под HLFS. Пользуйтесь, кому надо.

Кстати, а на чём сделан i810 tvout?

Я заморачивался в своё время - нашёл в завалах сети закрытую чтуку какую-то, которая дёргала 7007 кронтел.

Authors:
Matt Sottek: <matthew.j.sottek@intel.com>

Не это?

>Кстати, а на чём сделан i810 tvout?

Исходные тексты i810tvout на с. Родительская система Debian. В моей SUSE собирается, да и в любой другой должен собираться при наличии пересобранной библиотеки libpci и соответствующих ей заголовочных файлов. Я использовал самый последний pciutils-dev из deb. Номер сейчас не вспомню. Так же бинарный i810tvout из GeeXboX у меня заработал, с некоторыми оговорками (не связанными с uClibc) под uClibc. Под uClibc не собирал пока.

http://i810tvout.geexbox.org/

>нашёл в завалах сети закрытую чтуку какую-то, которая дёргала 7007 кронтел

:)))
Вы совершенно правы.
video out chip is used on card (on i810, it's a chrontel 7007)

То есть i810tvout для 7007

eg. the ch7007 datasheet is available directly on chrontel website

Как замечательно, что Вы написали об этом.

Вы будете смеяться, но ни разработчик i810tvout Aurelien Jacobs / ни я не смогли найти этот закрытый intell/овский драйвер, когда он снова понадобился.

Ещё один весёлый вопрос до сих пор :) , как, вероятнее всего, и на чём, организован tvout c i855GME?
Все производители молчат, как партизаны... :)

Может быть у Вас есть предположение? :)

> Вы будете смеяться, но ни разработчик i810tvout Aurelien Jacobs / ни я не смогли найти этот закрытый intell/овский драйвер, когда он снова понадобился.

Могу дать :)) У меня он сохранился :)

>Ещё один весёлый вопрос до сих пор :) , как, вероятнее всего, и на чём, организован tvout c i855GME? Все производители молчат, как партизаны... :) Может быть у Вас есть предположение? :)

Это врядли :( Я уже перестал с этим заморачиваться.

Да, кстати, он в архиве и не сохранился - только в "ууюках" в листе рассылки уже не помню где(откуда я его и выдрал)

Я там в новости про выход uClibc 0.9.27 ответил.

Вопрос к Anonymous :) Получилось ли портировать i810tvout для работы на 855GME?