Наконец-то HLFS alpha

Что и требовалось доказать. Это следовало ожидать.
Как я и предрекал :), цитирую самого себя:
http://www.linux.org.ru/view-message.jsp?msgid=509727
...собрал я таки x86 opie новую. Причём отказался от lfs, причём собрал на uclibc полностью...
http://www.linux.org.ru/view-message.jsp?msgid=675288

На мой взгляд uClibc - будущее линукс.
И наступает оно даже быстрее, чем можно было предполагать.

С улучшающейся поддержкой tinyx, если вoобще касаться графики, в крайних buildroot uClibc-cvs, возникают сомнения в эффективности следования qt и продолжении рихтования opie под х86. Это неплохо, но может быть лучше и быстрее.

Более того, я бы сказал так: а зачем hlfs и тем более lfs, когда есть собственно uClinux?

Просто все патчи расширяющие стандартные методики секурити контроля снижают общую производительность. Чтобы иметь "право на жизнь" такие дистры вынуждены искать способы самооблегчения.

PS : Идеологические слэши забыл ;) PPS: Ты бы патчи опайные вывалил ... Или это добро собирается уже без хирургии ?

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

Domenick кинь хотя бы пару хинтов на тему сборки opie. А то не всем дано "рубить" в плюсах. Но насколько видно при сборке там половина свойств qt-embedded виджетов в сырцах этого qte отсутствует :[ Примитивные вещи вроде получилось позатыкать пустышками, но на более сложных - заблудился.

Разница в размерах различающихся на порядки практически без потерь в функционале. А отсюда и производительнось. Да в принципе можешь сам глянуть на uClibc.org сходи там в данлоадсы - увидишь сколько это чудо весит ;)

>а зачем hlfs и тем более lfs, когда есть собственно uClinux?

собственно, прочитать на что рассчитан uClinux не судьба?

Если uClibc может то же что и glibc то почему бы и нет ? Linux тоже изначально был лабораторной работой...

"Идеологические слэши" - это грамотно! :). Порадовал unsaid старика. Никто не забыт, ничто не забыто :).
Меня тут всем колхозом пропесочивали, я решил ради идеи не быть упёртым :) Что бы всё же донести до людей факел света :). Прометей я наш. :) Из двух упёртых, кто-то же должен оказаться умнее :).
http://www.linux.org.ru/view-message.jsp?msgid=710040

Патчи онлайн я бы с удовольствием. Но ты про opie или про buildroot? Дело в том, что opie я шил, как мог :). Никакие патчи не писал, исправлял ошибки и всё. Осталось ощущение, что тогда всё это сверъхъмуторно шло. Потом, как съехал на uClibc, так в ней всё и возюкаюсь, готовлю под opie. Дело в том, что тестовая система 486sx ноут без fpu, мой крайний uClibc buildroot не соберается только по этой причине, ошибку не могу исправить, времени было мало разобраться. Я им отписал конечно.
http://www.uclibc.org/lists/uclibc/2004-December/010680.html
Сам попробуй, без fpu не соберётся.
По любому другому, buildroot c крайними gcc, linux-headers, и так далее собирается без проблем, даже для 4ки.

Да и не хочется постить кривизну, когда очень сырое, правда под определённым, демонстрационным :) ракурсом выглядит отлично.
Я думаю вообще отдельный проект завести, может кому/то будет интересно.
Сейчас я задумался, а действительно ли opie лучше?
Ведь было как: lfs -> opie -> uclibc.
Теперь получается uclibc -> ?
Вот некоторая информация для размышления:
http://pages.plotinka.ru/~estyler/index.html

Извини, в двух словах я могу, но опасаюсь быть не точным. Сейчас Здесь с этим строго :).
http://www.uclibc.org/about.html
Не просто так же lfs стал съезжать на uclibc :). Я lfs/у ещё в начале года написал: ухожу от вас в uClibc :). Можешь посмотреть в mail листе. Год думали :).

unsaid в целом верно сказал. Довольно точно.

Я имел ввиду сборку qte+{qtupia|opie}. Qtopia явно тянет свойства которые в сырцах qte отсутствуют или висят с баннером deprecated.

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

В принципе пробовал Directfb-шный lite, вроде ничего так, но учитывая что он еще глубоко development портировать под него что-то смысла практически не имеет. На данный момент более-менее актуально пользовать QTE поскольку имеется хоть какой-то набор функциональных приложений. Gtkfb - почти не имеет смысла, единственное функциональное приложение Gtk-demo ;) остальное слишком сильно увязло в Иксах. Так что пока альтернатив нет.

>собственно, прочитать на что рассчитан uClinux не судьба?

:) Нда. Даже не знаю, как на такое отвечать, что бы никого не обидеть. Как бы читаю. Иногда снится да же, фигурально выражаясь :).

uClibc относительно молодой развивающийся проект. Сегодня он рассчитан на одно, завтра на несколько иное, например на нечто большее. Мы определяем, на что он будет рассчитан. Я в ровном соответствии с идеологией открытых систем и в соответствии с направлением uClibc на малые и встроенные системы адаптировал к нему opie и далее на х86 архитектуру. Теперь можно с большей определённостью сказать, что uClibc рассчитан и на opie. Если этого, например, хватит, что бы организовать, рабочее место в каком-нибудь банке при достаточной функциональности за, на порядок меньшие деньги, можно будет сказать, что uClibc рассчитан на применение и в desktop/ах ? Более того, это можно сказать уже давно. И так далее.

Я далеко не сильно рублю в плюсах. Пользуюсь тем, что когда-то учил. Дело в том, что последовательность шагов сверхъкривая. Это в одном комментарии не опишешь. Надо заводить отдельную правильную страничку. Но может быть есть смысл не заморачиваться с opie. Вот, что я хочу тебе сказать. Тем более пока они все ждут qte-4. И будут на неё переползать какое-то время. Я стал медленно разочаровываться в opie. Стала толстеть. И все эти qt-шные довески. Присутствует тяжеловесность. Раньше альтернативы я не видел. Сейчас, нужно убедиться, что нет ничего лучше и тогда возвращаться к opie, в обратном случае, оставить её. Вот привлекают стандартная возможность buildroot uClibc -> tinyx, мне надо это получше изучить. Отпишу позже, сейчас время поджимает :).

Ok! Желаю удачи!

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

Спасибо. Удача нам не помешает. Я сейчас просмотрел свои ответы. Мрак :). В смысле правописания. Нет, нельзя мне так. Надо корректнее, тем более, раз согласился с предложенными условиями. Оправдывает лишь то, что вторые сутки не сплю :). Я сейчас постарался вдуматься в то, что с этим hlfs происходит. С одной стороны хорошо. Этого не хватало. В основном это некоторое приближение к пользователю.

С другой стороны, возникает несколько вопросов. Прежде всего, отметим, основное, что вынесено в манифест hlfs: "The HLFS team provides the "Hardened LFS" book, which teaches some foundational security principles and how to make an LFS/BLFS system more secure." То есть основной упор сделан на безопасность.

Но почему же "HLFS has just released its first alpha version. Version 0.1 includes Uclibc-CVS, gcc-3.4.3, binutils-2.15.92.0.2, and linux-2.6.7. The base of this book is taken from current LFS-unstable with some changes necessary for proper functioning of various security features." ? (кстати, вот набор, с которым развлекался я: uClibc-CVS, gcc-3.4.3, binutils-2.15.92.0.2, and linux-2.6.9, такое совпадение можно отнести только на счёт buildroot uClibc). То есть безопасность безопасностью, а реально речь идёт о практически полном соответствии конфигурации uClibc системы, с наиболее свежими версиями представленных пакетов. Немного удивляет, что в hlfs неверно, называется uClibc - Uclibc. Разработчики (www.uclibc.org), специально поясняли, как правильно записывать название uClibc. Такое впечатление, что сторонники lfs, стараются "в последнюю минуту вскочить в уходящий поезд" :). Под лозунгом: "Безопасная система". Не удивляет, что ведущую роль в hlfs играют Ryan Oliver и Robert Connolly, одни из наиболее компетентных, на мой взгляд, в lfs, сужу, в основном, по сообщениям в подписном листе. Так же, моё мнение, что сейчас uClibc на порядок лучше чем, что-либо подобное. Что дают lfs книги? Позволяют человеку собрать lfs систему. Но человеческий фактор ещё никто не отменял. Вероятность ошибок во время lfs сборки очень велика, достаточно посмотреть сообщения в подписных листах. В чём гениальность buildroot uClibc? На моей памяти, и в отличии от lfs, единственная система, которая, в соответствии с первоначально заданной конфигурацией, делает всё сама, включая загрузку пакетов, на выходе выдавая один единственный файл, который может быть смонтирован и/или запущен, как новая независимая, не обязательно х86 ос, причём, точно подогнанная под выбранные аппаратные возможности и с выбранным базовым набором приложений. Вот это действительно сильно! Кто же эти скромные герои? :) Это, естественно, прежде всего Erik Andersen - руководитель проекта и главный разработчик uClibc.

В продолжение. Мало того, основа родной uClibc системы - рациональность. То есть вы не только получаете то, что заказывали, но и в наиболее эффективном виде. Складывается мнение, что при вырастании проекта до определённого уровня, он теряет сторонников по причине малой практической эффективности контроля. Это я о glibc. uClibc показывает: "Можно сделать всё то же самое, но гораздо лаконичнее". И размер будет на порядок меньше и быстродействие на уровне или выше. Вот это мастерство :). Не зря в hlfs - uClibc выбрана именно для безопасной системы - первостепенный критерий в настоящее время. Такой выбор hlfs - лучшее подтверждение силы uClibc.

Конечно, не всё так радужно :). Нужно отметить, что сейчас версия uClibc - 0.9.26 от 3 января 2004. Правильно, ответил Erik Andersen на вопрос, почему не выходит 1, мол давно пора. "Пока не будут реализованы все запланированные улучшения, 1 не будет". Всё чётко, всё по плану. Вот список todo, даёт некоторое представление о разнице между настоящей uClibc и glibc: http://www.uclibc.org/cgi-bin/cvsweb/uClibc/TODO?rev=1.59 Так кратко о uClibc.

Теперь в дополнение небольшой комментарий по поводу gui при uClibc. Две эти вещи связаны мало. uClibc предоставляет платформу, в том числе, и я бы добавил, прежде всего, разработчику. Интересно, что в настоящее время в buildroot используется tinyx. Этим в целом всё сказано :). Когда, данное направление не было определено, возможно, привязка к uClibc системе - opie имела не только творческий интерес :). На мой взгляд, популяризация линукс, в том числе, с точки зрения , системы с обратной связью, когда новые сторонники, начиная с определённого момента, начинают участвовать в разработке и улучшении, до сих пор, в значительной степени, определяется такими простыми вещами, как, например, графический интерфейс пользователя. Это безусловно, многогранный вопрос, со времён xerox :). Появление hlfs, как своеобразной обработки uClibc с упором на безопасность, использование в buildroot таких пакетов, как busybox, tinylogin, tinyx и подобных - проявляет тенденцию. Тенденцию стремления к минимизации и рациональности. Я не хочу сказать, что на это обратили внимание только сейчас, я говорю, что этому стало уделяться больше внимания. На мой взгляд, это логично: лаконичная система более жизнеспособна. Вот пример, популярным является изменение фона рабочего стола в графической среде. С определённой точки зрения - это нерационально. Убеждён, что любитель подбирать лучший фон никогда не сможет окончательно остановиться, на чём-то одном. Всегда будет находиться лучшая картинка, в силу специфики восприятия человека. Памяти под картинку, её передачу расходуется больше, чем в случае, например, однотонного фона. Добавим время, потраченное на поиск, передачу и установку картинки и тому подобное. Нерационально. Вопрос восприятия рабочей среды. Возможно, пока, мы готовы признать, что присутствие определённого изображения на рабочем столе, воспринимается более эмоционально, чем осознание, скажем, "энтропийной чистоты" однотонного фона. Это относится и к устройству операционных систем. Последствия разбухания операционных систем и приложений - это прежде всего проблемы с безопасностью и потери рабочего времени. В бардаке, ошибки возникают и прячутся проще всего. Многие бы хотели работать в гармоничной ос с достаточным набором функций и лаконичным интерфейсом, направляя время, тратящееся сейчас на настройку, как раз на то, для чего прежде всего предназначен персональный компьютер. Дополненная подходящим gui и, возможно, усиленная, в плане безопасности по hlfs, uClibc система, на сегодня, лучший образец, на базе которого можно решать рассмотренную задачу.

вообще-то, я говорил именно о uClinux (uCkernel)
www.uclinux.org/description
о uClibs я вообще ничего не говорил

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

>Разница в размерах различающихся на порядки практически без потерь в функционале.

А стоит ли? Диски нынче дешевы.

>А отсюда и производительнось.

Как и процессоры и память.

> А стоит ли? Диски нынче дешевы.

Это ИМХО тупиковый путь. Согласен диски дешевы, но диски находятся на закате своего существования, на смену им прийдут ППЗУ - просто эту эволюцию от механических накопителей к электронным тормозит тот фактор, что пока по скорости флэшки проигрывают хардам, но по энергозатратам и стойкости к естественным физическим воздействиям далеко впереди.

> Как и процессоры и память.

Эффективное использование и процессоров и памяти и есть прогресс. А подстраивание под конечного пользователя - регресс, искусственный потолок развития. Я согласен, что человеку глубоко фиолетово за сколько наносекунд происходят те или иные операции и сколько мегабайт впустую занято на 80 гигабайтном винте, главное чтобы отображалось все "шустро". Человек - не верх совершенства и измерять производительность и эффективность системы не здравым смыслом, а скоростью визуальной реакции среднестатистического клерка со зрением минус полтора и пивным животиком - ИМХО глупо. А вообще это все философия и вообще мутная штука - я могу и ошибатся.

>Это ИМХО тупиковый путь. >Эффективное использование и процессоров и памяти и есть прогресс.

И руками и ногами ЗА! Только объясните это жабщикам. Выше был камень в их огород.

>Ну гармоничная ОС на данный момент это еще мечта.

Согласен. И согласие в понимании того, к чему желательно стремиться уже результат :). Не "открою америку" если скажу, что отсутствие такой системы в мире opensoft это прежде всего отсутствие стандарта и, в конечном итоге то, что все люди разные. Уж сколько это обсуждалось. Так же обсуждалось и то, что эта ситуация правильная. Аналогично теории развития организмов.

>А вот развитие носимых или embedded систем - это воплне реальная задача.

Снова согласен. http://www.linux.org.ru/view-message.jsp?msgid=675288

>Не я не за то, чтобы все снимали с полок старые "четверки" и делали из них мобильные терминалы.

(У меня это лишь тестовая система - хорошо дисциплинирует :))

>неприятны высказывания вроде "да сейчас ОЗУ копейки стоит" "да проц проапгрейдить - один раз в кабак не сходить"

Вот вот. Это, как экологически чистый транспорт - трамвай :).

>Вот отсюда и это ожирение софта.

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

>вообще-то, я говорил именно о uClinux (uCkernel) >о uClibs я вообще ничего не говорил

Моё упоминание uClinux следует понимать, как пример использования uClibc. Мне сложно представить, как можно говорить о uClinux, не говоря о uClibc.

> И размер будет на порядок меньше и быстродействие на уровне или выше.

Бенчмарки можно увидеть? Мои тесты годичной давносит показывали
отставание в скорости от glibc. У кого есть какие данные на этот счёт?
Или имеется в виду статическая линковка?

unsaid, ты на мой взгляд очень правильно понимаешь, о чём идёт речь. :)

Вот сколько времени прошло с начала массового распространения мобильных телефонов? Лет 10? Можем мы признать, что на смену десктопам идут ноуты, а мобильные телефоны порой обгоняют по возможностям ноутбуки 5-летней давности? Если сейчас предоставить бесплатно :) тёте Маше или Васе Пупкину персональное устройство в формате мобильного телефона с действительно "итуитивно понятным" :) интерфейсом, возможно так же голосовым управлением, решающее спектр наиболее распространённых задач с запасом, теперь, как можно оценить вероятность и сроки распространения такой системы? Где, гипотетически, если исключить неспортивные особенности, были бы мобильные окошки, не самое быстрое творение, к тому же далеко не бесплатное? Радует, что для подобной системы уже практически всё готово. Остаётся собирать. В определённой, псевдокоммерческой реинкарнации, и не только, это уже кое-где работает. Один вряд-ли я справлюсь с подобным проектом :). Как ты оцениваешь, вероятность развития такого проекта? Готов поучаствовать (теоретически :))?

>Бенчмарки можно увидеть? Мои тесты годичной давносит показывали отставание в скорости от glibc. У кого есть какие данные на этот счёт? Или имеется в виду статическая линковка?

Что касается размера, тут всё ясно, я надеюсь. Вопрос на счёт тестов производительности в целом верный, но, на мой взгляд, несколько преждевременный и не совсем корректный в данном контексте. Я надеюсь, Вы не будете спорить, что тесты производительности черезвычайно многогранная вещь. Непосредственно uClibc система может быть сконфигурирована очень по-разному :). И с чем вы собираетесь её сравнивать? Для каких приложений, с какой системой? uClibc систему для, например, аlpha или powerpc архитектуры с чем? С тем же, но glibc? Или, например, статическую систему на основе uClibc c точно такой же на основе uClibc динамически слинкованной, но размещённой и работающей полностью в оперативной памяти? :)

> Как ты оцениваешь, вероятность развития такого проекта? Готов поучаствовать (теоретически :))?

Весьма высока. Учитывая, что как ты уже упомянул техническая и софтверная база реально позволяет это сделать. А поучаствовать было бы интересно. Если не трудно напиши на unsaid at mail.ru Или оставь свои контакты.

Отпишу. Может быть, что-нибудь придумаем. Единственно, возможно, не так быстро, если ты не против. Я сторонник всё делать размеренно. Сейчас, вот снова про cvs up ил buildroot. Смотрю сообщения в uClibc mail list по поводу hlfs. Там это так же не прошло незамеченно.

И ещё: Не помню кто, сказал, что только дилетанты создавали, что-то действительно новое :). Собственно, нам и создавать ничего не надо. "Просто" :) собрать :). Ты не против, если на указанный тобой адрес напишут те, кому будет интересно поучаствовать в проекте? Если такие будут :). Пишите.

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

Отправил сообщение Дим.

> Вопрос на счёт тестов производительности в целом верный, но, на мой взгляд, несколько преждевременный и не совсем корректный в данном контексте.

Почему? Проблема скорость запуска/исполнения приложений очень актуальна
для мобильных устройств с далеко не самыми сильными процессорами. Более
того, мне кажется, что в долгосрочной перспективе она гораздо более
важна, чем, например, размер. Ибо ёмкости flash-накопителей растут явно
быстрее, чем частота CPU. А частота CPU в свою очередь упирается в
потребление энегии и проблему отвода тепла. Ситуация в ближайшее
время может сложиться так, что объём накопителей сравняется с
десктопными системами, а мощность CPU остановится примерно на отметке 1ГГц.

> И с чем вы собираетесь её сравнивать? Для каких приложений, с какой системой?

Я собираюсь? Это вы по идее должны были сравнить - те, кто говорил,
что быстродействие uClibc на уровне или выше glibc.

Ну и ещё последний вопрос: кто-нибудь рассматривал в качестве
альтернативы dietlibc? Чемпион по скорости и по размерам бинарей,
между прочим... Эта библиотека и меньше, и быстрее uClibc.

>Ибо ёмкости flash-накопителей растут явно быстрее, чем частота CPU.

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

> Я собираюсь? Это вы по идее должны были сравнить - те, кто говорил, что быстродействие uClibc на уровне или выше glibc.

Мы пока, к счастью, ещё ничего никому не должны :). Говорил я вот что: > на уровне или выше

Это моё мнение, основанное на опыте работы, в большой степени, надо признать, интуитивное. Но достаточно посмотреть список todo для uClibc, о котором я упоминал выше, что бы убедиться, что в определённых частях uClibc система пока не опережает glibc систему. Характерный пример, отсутствие сейчас в uClibc поддержки: for Linux 2.6.x NPTL pthreads

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

>Ну и ещё последний вопрос: кто-нибудь рассматривал в качестве альтернативы dietlibc? Чемпион по скорости и по размерам бинарей, между прочим... Эта библиотека и меньше, и быстрее uClibc.

Спасибо за упоминание. Я вспомнил, что только слышал о dietlibc, когда вы её упомянули. Так что здесь пока ничего не могу сказать.

> Мы пока, к счастью, ещё ничего никому не должны :)

Не должны до тех пор, пока молчите. А слово выронили - отвечайте по всей строгости ;)

> Это моё мнение, основанное на опыте работы

Увы, в наше время мнения никого не волнуют. Только факты имеют вес ;(

> Предложите тестовую аппаратно-программную конфигурацию

Боже, какой "квадратное" мышление у вас... Простейшие вещи делать такими
сложными. Может ещё госкомиссию собрать дял приёмки тестов?

Вот только не надо про "жабщиков" ничего говорить. Уж эффективнее, чем жаба сложно что-либо предложить. Некомпетентность Вас не красит. Вот предлагаю "придумать" тест программисту на С и реализовать его на "жабе", программистом Java и программистом С и потом наоборот. Думаю результаты Вас как минимум удивят.

а. 486. вопрос "а на... надо" снят. потому как на 2800 атлоне кде летает. и никаких напильников

>Не должны до тех пор, пока молчите. А слово выронили - отвечайте по всей строгости ;)

Хорошо, постараемся :).

> Это моё мнение, основанное на опыте работы >Увы, в наше время мнения никого не волнуют. Только факты имеют вес ;(

Это понятно. Согласен.

>Боже, какой "квадратное" мышление у вас... Простейшие вещи делать такими сложными. Может ещё госкомиссию собрать дял приёмки тестов?

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

Это анонимус, который предлагал свой скрипт для CБОРКИ LFS (кто видел тот форум). Я его таки принес. Там есть и скрипт для сборки BLFS в том виде, в каком я работал. Глянув бегло на hlfs book(на состав пакетов), могу предположить, что мои скрипты вполне подойдут с минимальными изменениями и для этого. Предлагаю. Кроме того, я на выходных немного повозился с BLFS-частью, добавив кое-что. Вложил также измененные pkgutils от слаки, которыми пользовался и для автосборки и их же ставил в систему. Размер tar.bz2 архива всего этого дела около 60К. Куда скинуть?

>кто видел тот форум

Вы можете разместить ссылку на упоминаемое обсуждение?

Это было буквально несколько дней назад. Обсуждалась LFS-6.0.