Представлен отчёт о развитии проекта FreeBSD с января по март 2012 года. После выхода 13 января FreeBSD 9.0 (http://www.opennet.ru/opennews/art.shtml?num=32749) в первые месяцы 2012 года основные усилия разработчиков были направлены на подготовку релиза FreeBSD 8.3 (http://www.opennet.ru/opennews/art.shtml?num=33632), который был выпущен в середине апреля и кроме поддержки нового оборудования включал результаты бэкпортирования некоторых возможностей из FreeBSD 9.
Основные достижения:
-
Система
- В базовую систему FreeBSD 10.0-CURRENT и 9.0-STABLE по умолчанию установлен (http://wiki.freebsd.org/BuildingFreeBSDWithClang) распространяемый под лицензией BSD компилятор Clang 3.0. В FreeBSD 10.0-RELEASE принято решение задействовать Clang в качестве системного компилятора по умолчанию, GCC будет оставлен в качестве опции. В настоящее время, как минимум для FreeBSD 10.0-CURRENT обеспечена полноценная пересборка базовой системы и ядра в конфигурации GENERIC без предупреждений при сборке с опцией "-Werror" (для изменённых конфигураций ядра предупреждения пока могут наблюдаться).В src.conf добавлена опция WITH_CLANG_IS_CC, при установке которой Clang по умолчанию будет установлен в качестве базового системного компилятора, т.е. заменит собой /usr/bin/cc, /usr/bin/c++ и /usr/bin/cpp. GCC пока остаётся в системе, даже при использовании опции WITHOUT_GCC, gcc будет доступен как /usr/bin/gcc, /usr/bin/g++ и /usr/bin/gcpp. Кроме того, в src.conf добавлена опция WITH_CLANG_EXTRAS, которая позволяет задействовать при сборке несколько дополнительных инструментов, созданных в рамках проектов LLVM и Clang, таких как 'llc' и 'opt'. Подобные утилиты могут оказаться полезными для работы с биткодом LLVM (.bc) и ассемблерными файлами LLVM (.ll).
В настоящее время все усилия разработчиков направлены на обеспечение сборки и запуска всей системы FreeBSD с использованием Clang, в том числе проверку работы как можно большего числа приложений, включая порты. Пользователи могут существенно помочь в этом начинании приняв участие в тестировании и сообщая о наблюдаемых проблемах. Что касается сборки потров с использованием Clang, то в
это области также отмечается значительный прогресс: многие мэйнтейнеры уже адаптировали свои порты для работы с Clang, налажен процесс автоматической периодической проверки сборки портов с использованием Clang. Тем не менее в портах ещё можно встретить приложения, которые не могут быть собраны с Clang, как правило это очень старые программы, которые часто не собираются и с новыми версиями GCC.Из планов упоминается работа по импортированию в систему нового снапшота Clang, на базе которого будет сформирован релиз LLVM/Clang 3.1 (релиз ожидается в ближайшие дни). В Clang 3.1 ожидается улучшение поддержки кросс-компиляции, что поможет форсировать процесс обеспечения кросс-компиляции ядра и базовой системы FreeBSD для архитектур ARM и MIPS.
- Продолжается работа по созданию для FreeBSD полноценного С++ стека, целиком распространяемого под лицензией BSD и независящего от кода проекта GNU. Проведено расширенное тестирование и добавлены новые возможности, например, поддержка ARM EABI, в библиотеки: libc++ (реализация элементов, определённых в стандарте C++11) и libcxxrt (реализация спецификации C++ ABI). Использование предварительной версии Clang 3.1 совместно с данными библиотеками демонстрирует полное прохождение тестов на совместимость со стандартом C++11. По умолчанию библиотеки пока не используются, так как библиотека libc++ не совместима с поставляемым в базовой системе gcc и может работать только с clang. Переход на новый C++ стек ожидается во FreeBSD 10, одновременно с задействованием по умолчанию Clang.
Реализация (http://www.opennet.ru/opennews/art.shtml?num=31857) расширенных функций для работы с локалью (xlocale), от которых зависит развиваемая проектом LLVM библиотека libc++, протестирована c множеством портов, изначально написанных для реализации xlocale от проекта Darwin. Выявленные в процессе тестирования ошибки исправлены, код библиотеки планируется выпустить в составе FreeBSD 9.1.
Во FreeBSD-CURRENT сборка libsupc++ теперь осуществлена в виде разделяемой библиотеки, что позволяет упростить замену данной библиотеки на libcxxrt от проекта LLVM. Выбор какие из библиотек использовать, GNU libsupc++ или BSD libcxxrt, осуществляется через изменение настроек в libmap.conf. Если в качестве libstdc++ используется libcxxrt, пользователь имеет возможность связывания с обоими библиотеками, использующими libstdc++ и libc++, что значительно упрощает миграцию.
Из открытых задач остаётся создание замены для некоторых частей libgcc_s и системы динамического связывания, проведение тестирования сборки портов с libc++ (большинство портов без проблем собираются, но остаются такие, которые жестко привязаны к libstdc++ или требуют патчей), переход на сборку и использование libc++ и libcxxrt по умолчанию (когда clang станет компилятором по умолчанию в базовой системе); удаление libstdc++ из базовой системы и помещение в порты для обеспечения обратной совместимости;
- Возобновлена работа над проектом FSC (http://people.freebsd.org/~trhodes/fsc/) (FreeBSD Services Control), в рамках которого развиваются похожие на Solaris SMF и daemontools инструменты для управления и мониторинга работой системных сервисов. Для контроля за работой сервисов используется фоновый процесс fscd, сервисы добавляются при помощи утилиты fscadm. В случае аварийного завершения работы сервиса, fscd распознает падение процесса и запускает сервис вновь. По сравнению со сторонними пакетами, такими как daemontools, система FSC имеет несколько преимуществ, например fscd использует push-нотификацию вместо поллинга (отправляет уведомления, не требуя периодического опроса состояния). Кроме того, fscd является внутренней подсистемой, легко интегрируемой в rc.d-инфраструктуру FreeBSD и полностью поддерживаемой разработчиками (daemontools является неподконтрольным портом для которого можно лишь поддерживать набор патчей). В настоящее время подготовлена (http://people.freebsd.org/~trhodes/fsc/fsc.tar) новая версия FSC и связанного порта (http://people.freebsd.org/~trhodes/fsc/fsc-port.tar) со вспомогательными утилитами, поддерживающая большее число опций, добавляющая новый файл конфигурации fscd.conf, поддерживающая отладочный режим и поставляемая с обновлённым rc.d-скриптом для запуска fscd;
- Достигла стабильного состояния распространяемая под лицензией BSD утилита sort (http://www.freebsd.org/cgi/cvsweb.cgi/ports/textproc/bsdsort/), написанная с целью замены GNU sort. Отмечается, что производительность BSD sort находится на уровне GNU sort и поддерживаются все возможности присутствующие в GNU sort 5.3.0 (данная версия поставляется во FreeBSD). Кроме того в BSD sort реализован ряд дополнительных возможностей, например, корректно поддерживаются многобайтовые кодировки, в то время как GNU sort 5.3 в этой области испытывает проблемы. Из планов на будущее отмечается интеграция новой утилиты во FreeBSD-HEAD в качестве альтернативы, устанавливаемой под именем bsdsort (после того как будет ясно, что всё работает как задумано, утилита GNU sort будет удалена, а bsdsort переименована в sort). Также планируется интеграция в BSD sort поддержки многопоточной сортировки и реализация некоторых возможностей, которые присутствуют в последней версии GNU sort 8.15;
- Ведётся работа (http://svnweb.freebsd.org/base/user/gabor/tre-integration/) по замене устаревшей реализации регулярных выражений в libc на библиотеку TRE (http://laurikari.net/tre/), распространяемую под лицензией BSD, поддерживающую многобайтные символы, совместимую с POSIX и работающую не хуже других альтернатив. Практически завершена разработка нового эвристического метода выявления соответствий с поддержкой поиска по множественным шаблонам (multi-pattern), который отличается заметным ускорением поиска по шаблонам. Из планов на будущее отмечается реализация поддержки возможностей, специфичных для GNU ...URL: http://lists.freebsd.org/pipermail/freebsd-announce/2012-May...
Новость: http://www.opennet.ru/opennews/art.shtml?num=33836
А когда KMS запилят уже?
когда тестеров будет больше и их грамотных сообщений об ошибках...
> когда тестеров будет больше и их грамотных сообщений об ошибках...Интересно, как можно тестировать то чего нет? // тестеры
>> когда тестеров будет больше и их грамотных сообщений об ошибках...
> Интересно, как можно тестировать то чего нет? // тестерыне притворяйся шлангом http://wiki.freebsd.org/Intel_GPU
но это еще НЕ в голове, пока что...
Так допилили уже. Правильный вопрос - когда включат в базовую систему - тут да, нужно ещё тестирование на разном железе.
> Так допилили уже. Правильный вопрос - когда включат в базовую систему -
> тут да, нужно ещё тестирование на разном железе.не допилили - иначе бы оно уже было бы в голове...
Тогда ответ - 50/50: http://lists.freebsd.org/pipermail/freebsd-current/2012-May/...
> Тогда ответ - 50/50: http://lists.freebsd.org/pipermail/freebsd-current/2012-May/..."This allows to start the process of importing the new Intel
GPU driver into HEAD.""This allows to start"
и там ниже по тексту куча нерешенных вопросов.
И?
куча нерешенных вопросов это 2 вопроса? Так они совсем ерундовые и типа "как лучше для вас?"
> куча нерешенных вопросов это 2 вопроса? Так они совсем ерундовые и типа
> "как лучше для вас?"То есть при решении этих 2-х вопросов - другие возникать не будут?
отвечу по-одесски...
> Возобновлена работа над проектом FSC (FreeBSD Services Control), в рамках которого развиваются похожие на Solaris SMF и daemontools инструменты для управления и мониторинга работой системных сервисов.Что-то нынче во всех свободных никсах начали выкидывать старые системы init, и писать с нуля новые.
Видимо, исторический момент уже назрел - старые иниты не отвечают современным требованиям, даже если подпереть костылями.Хотя имхо лучше бы launchd таки допортировали - там очень вкусная фича работы с сокетами, как в systemd.
Это вроде больше похоже на watchdog. Фряшники никогда особо не напрягались относительно скорости непосредственно запуска.
> Это вроде больше похоже на watchdog. Фряшники никогда особо не напрягались относительно
> скорости непосредственно запуска.Еще скажите, что FSC не поддерживает распараллеливания =)
> Еще скажите, что FSC не поддерживает распараллеливания =)
> инструменты для управления и мониторинга работой системных сервисов.Ты вообще о чём?
Это _НЕ_ замена бсдшному иниту.
> Еще скажите, что FSC не поддерживает распараллеливания =)FSC и распараллеливание параллельны.
Потому что BSD-шный инит уже давно поддерживает параллельный запуск служб.
> Потому что BSD-шный инит уже давно поддерживает параллельный запуск служб.А можно поподробнее? Я не в курсе. Если будет какой-то пруф, буду признателен.
А на кой упираться в скорость запуска? Сервер должен работать, работать, работать... Запуск-перезапуск - это крайне редкое явление, не влияющее на работоспособность системы. Uptime свыше года - это же нормально! Если юзеры настолько привыкли к работоспособности, что не могут минуту обождать - дык воспитывать надо :-/
> А на кой упираться в скорость запуска? Сервер должен работать, работать, работать...
> Запуск-перезапуск - это крайне редкое явление, не влияющее на работоспособность системы.Точно! Есть тут неподалёку Супердом какой-то (с супен-Юниксами, видимо), шатдаунится чуть не сутки (ну, ладно, часов 8?), пассаны рассказывали. И ничего! Пообновлять прошивочек контролёров-бивисов на выходные выходят. Куда торопиться-то? ........
> Точно! Есть тут неподалёку Супердом какой-то (с супен-Юниксами, видимо), шатдаунится чуть
> не сутки (ну, ладно, часов 8?), пассаны рассказывали. И ничего! Пообновлять
> прошивочек контролёров-бивисов на выходные выходят. Куда торопиться-то? ........ОБС? )
> Точно! Есть тут неподалёку Супердом какой-то (с супен-Юниксами, видимо), шатдаунится чуть
> не сутки (ну, ладно, часов 8?), пассаны рассказывали. И ничего! Пообновлять
> прошивочек контролёров-бивисов на выходные выходят. Куда торопиться-то? ........опа. а мужики рассказывали, что фирмварь всякая на этих супедомах без шатдауна апгрейдится. обманывали, значит, вот оно чо...
> Uptime свыше года - это же нормально! Если юзеры настолько привыкли
> к работоспособности, что не могут минуту обождать - дык воспитывать надо
> :-/Больше года не обслуживаемая система - это правильно, да. У нас же счастье давно наступило, все паки на систему накатываются concurrently, секьюрити фиксы не выпускают, потому что все научились писать безгрешный код, и безопасники по итогам аудита за непатченые системы не дрючат, а даже наоборот, премии выписывают.
Скорость запуска это конечно няшка. Кому-то приятно,что система запускается супер быстро. Но мне главное чтобы система работала стабильно. А сколько уж там она запускается - всё равно. И если моя система работает стабильно, то я запускаю её от силы раз в день. И мне тут +/- минута роли не играет. Заодно успею сходить, чаю налить. Другое дело ноут. Но и там скорость запукса 25-30сек против 1 минута 30 сек не так уж и влияет, если только вам не надо выпрыгивая из поезда срочно посмотреть карту.
> Что-то нынче во всех свободных никсах начали выкидывать старые системы init, и
> писать с нуля новые.
> Видимо, исторический момент уже назрел - старые иниты не отвечают современным требованиям,
> даже если подпереть костылями.Лолшто? Это ни разу не замена иниту. Даже рядом не. Это скорее расширение текущего инита - добавлен сторонний демон, который следит за тем, рухнул сервис или нет, если что - поднимает.
> Хотя имхо лучше бы launchd таки допортировали - там очень вкусная фича
> работы с сокетами, как в systemd.Так ли оно нужно? И справедливости ради: Это в systemd фича стырена из launchd, а не наоборот.
> Лолшто? Это ни разу не замена иниту. Даже рядом не. Это скорее расширение текущего инита - добавлен сторонний демон, который следит за тем, рухнул сервис или нет, если что - поднимает.Замена, замена. Кто теперь службы запускает, сам инит, да? :)
Многие новые иниты запускаются старым инитом, который таким образом удаляется от дел. Достаточно вспомнить SMF в Solaris и OpenRC в Linux.> Так ли оно нужно?
Да. Более просто и прозрачно, более эффективно, более юниксвейно.
> И справедливости ради: Это в systemd фича стырена из launchd, а не наоборот.
Какая разница, во фре сейчас не ни того, ни другого.
> Замена, замена. Кто теперь службы запускает, сам инит, да? :)Да. Ты вообще читал, что такое FSC?
> Многие новые иниты запускаются старым инитом, который таким образом удаляется от дел.
> Достаточно вспомнить SMF в Solaris и OpenRC в Linux.Очень рад за пользователей SMF и OpenRC.
>> Так ли оно нужно?
> Да. Более просто и прозрачно, более эффективно, более юниксвейно.Убил.
>> И справедливости ради: Это в systemd фича стырена из launchd, а не наоборот.
> Какая разница, во фре сейчас не ни того, ни другого.Потому что не нужно. Хотя, боюсь, следуя веяниям моды сделают. Хотя вообще этим надо не иниту заниматься, по-хорошему.
> Да. Ты вообще читал, что такое FSC?Я читал сорцы. Сейчас FSC - вообще ничто. Все еще впереди.
>> Да. Более просто и прозрачно, более эффективно, более юниксвейно.
> Убил.Вы ходите поспорить с разработчиками UNIX (Mac OS X) о юниксвее?
> Потому что не нужно.
Вам - не нужно. Людям - нужно.
> Хотя, боюсь, следуя веяниям моды сделают. Хотя вообще этим надо не иниту заниматься, по-хорошему.
Как раз только инит (или его аналог) и может этим заниматься. Курите матчасть.
> Я читал сорцы. Сейчас FSC - вообще ничто. Все еще впереди.Я хз, что ты там читал, но судя по твоим постам - не то что-то (про параллельность это ведь ты писал?). Ну уж про замену иниту точно ты писал, а это грамотная метановая атака на лужу.
Сейчас FSC - то, что и должно быть. Демон, который мониторит работу остальных, поднимает если упали и пишет об этом в логи. Просто и гениально.
Или вы предлагаете конструировать монстра вроде фатально уродливого systemd, который содержит в себе всё, что только пришло в воспалённый мозг разработчика?
> Вы ходите поспорить с разработчиками UNIX (Mac OS X) о юниксвее?
Ага. То, что макось сертифицирована как юникс вовсе не является подтверждением того, что она следует юниксвейным принципам. Как пример неюниксвейности - местный инит и графическая подсистема.
> Вам - не нужно. Людям - нужно.
Базару 0. Но что-то мне кажется, большинству не нужно, кому нужно - пусть пилят.
> Как раз только инит (или его аналог) и может этим заниматься. Курите
> матчасть.Поттеринг головного мозга? Может тогда ещё всунуть в инит cron, jail, кастрированный ps, syslog и прочее, а заодно переименовать её в systemd?
Что касается курения матчасти, ок, скинь ка мне, где, кроме бреда гаррипоттеринга написано, что инит, похожий на помойку - это юниксвей?
И да, inetd и прочие аналоги должны этим заниматься. Но, соглашусь с тем, что в fsc это будет адекватно смотреться. Ибо fsc скорее inetd/xinetd/daemontools, чем инит.
>Как пример неюниксвейности - местный инит
> и графическая подсистема.Да Вы нуб, сэр. Графическая подсистема и инит как раз сделаны в полном соответствии с канонами.
> Да Вы нуб, сэр. Графическая подсистема и инит как раз сделаны в
> полном соответствии с канонами.Ммм. Интересно, это почему? Потому что представляют из себя унылые монолитные куски г-на? Или потому, что даже не обладают намёком на гибкость?
И вообще, я хочу слышать обоснования, а не оскорбления моей анонимной персоны, это не прикольно.
Мои аргументы:
В launchd впихнуто всё на свете, конфиги на xml, он принципиально не заменим (в макоси) ни на что иное.
Графическая подсистема делалась без намёка на нормальную сетевую прозрачность (как в иксах; то, что она в иксах щас работает через жопу вина не иксов, а нагромождения костылей и тулкитов) и практически слита с оконным менеджером и тулкитом (использование по-отдельности не предполагается).
> В launchd впихнуто всё на свете, конфиги на xml, он принципиально не
> заменим (в макоси) ни на что иное.Конфиги у него вполне себе текстовые. Вот если бы были бинарные - тогда были бы вопросы про юниксвейность.
Между прочим, в солярке тоже XML. В общем, стандарт современных UNIX-систем.А насчет заменимости - API у него есть, ничто не мешает написать аналог.
Только вот никто не пишет. Видимо, потому что launchd полностью устраивает.> Графическая подсистема делалась без намёка на нормальную сетевую прозрачность (как в иксах; то, что она в иксах щас работает через жопу вина не иксов, а нагромождения костылей и тулкитов)
А нагромождение костылей, в свою очередь, является логическим следствием уродливой архитектуры иксов.
> Конфиги у него вполне себе текстовые. Вот если бы были бинарные -
> тогда были бы вопросы про юниксвейность.
> Между прочим, в солярке тоже XML. В общем, стандарт современных UNIX-систем.ЕМНИП таки XML. В последней макоси. А то, что в солярке тоже XML - не оправдание. Нечитаемый и угрёбищный формат. Даже у поттеринга хватает ума не использовать его для конфигов.
> А насчет заменимости - API у него есть, ничто не мешает написать
> аналог.
> Только вот никто не пишет. Видимо, потому что launchd полностью устраивает.API у всего есть. А если нету - можно сделать костылями. Тока это всё равно не аргумент. Я говорил о возможности заменить его на свою реализацию инита, а не о написании своего launchd с тем же апи, но свой - это бред.
> А нагромождение костылей, в свою очередь, является логическим следствием уродливой архитектуры
> иксов.Нет. Это следствие того, что тулкиты развивались очень постепенно, впрочем, как и иксы. В итоге вместо переписывания под новые возможности всё лепилось поверх того, что есть. Из-за этого и проблемы. Впрочем, есть библиотеки, работающие напрямую с иксами. Например XCB.
Не, иксы не идеальны, но АДЕКВАТНЫХ альтернатив нету.
Libconfig предоставляет интересный вариант. Можно делать вложенные секции. Очень удобно. И разные типы данных. Гораздо более простой формат. Особенно визуально.
> А нагромождение костылей, в свою очередь, является логическим следствием уродливой архитектуры
> иксов.Архитектура офигенная и правильная, просто ее хотели применить не для тех целей - для которых она когда-то создавалась...
> Сейчас FSC - то, что и должно быть. Демон, который мониторит работу остальных, поднимает если упали и пишет об этом в логи. Просто и гениально.Пока что даже эта функциональность в нем реализована не до конца.
А какая появится в следующем мажорном релизе - еще неизвестно :)> Или вы предлагаете конструировать монстра вроде фатально уродливого systemd, который содержит в себе всё, что только пришло в воспалённый мозг разработчика?
На линуксе systemd+util-linux выполняет сейчас примерно ту же роль, как базовая система на фре - минимальный набор утилит, позволяющий запустить систему.
Вы, видимо, не в курсе, но сам демон там умеет только запускать и останавливать службы. Все остальное сделано через вспомогательные демоны.> Ага. То, что макось сертифицирована как юникс вовсе не является подтверждением того, что она следует юниксвейным принципам. Как пример неюниксвейности - местный инит и графическая подсистема.
Это ваше утверждение наглядно показывает, что вы ничего не понимаете в юниксвее :)
> Поттеринг головного мозга? Может тогда ещё всунуть в инит cron, jail, кастрированный ps, syslog и прочее, а заодно переименовать её в systemd?
Зачем? Есть же базовая система. Это примерно то же самое.
> Что касается курения матчасти, ок, скинь ка мне, где, кроме бреда гаррипоттеринга написано, что базовая система, содержащая более одного бинарника - это юниксвей?
fixed
> И да, inetd и прочие аналоги должны этим заниматься.
Для этого inetd должен запускать в самом начале загрузки (даже раньше syslog), и непрерывно работать до полного выключения (даже без права на перезапуск, иначе накроются все программы, запущенные через сокет-активацию). Юниксвейненький у вас inetd получился, нечего сказать :)
> Пока что даже эта функциональность в нем реализована не до конца.Как-раз эта и реализована. Давно уже, кстати. Сейчас больше доведением и отладкой занимаются.
> А какая появится в следующем мажорном релизе - еще неизвестно :)
Не интересовался на этот счёт.
> На линуксе systemd+util-linux выполняет сейчас примерно ту же роль, как базовая система
> на фре - минимальный набор утилит, позволяющий запустить систему.Отнюдь. Базовая система FreeBSD - 1) Не только минимальный набор утилит для запуска системы 2) В общем случае, отдельные утилиты не зависят друг от друга. А из портов можно поставить утилиты с дополнительным или замещающим функционалом - всё легко заменяется.
А Systemd обладает большим количеством дублирующего уже присутствующие в системе функционала. Оно огромно и избыточно.
> Вы, видимо, не в курсе, но сам демон там умеет только запускать
> и останавливать службы. Все остальное сделано через вспомогательные демоны.Прибитые гвоздями к systemd, круто, чё. Одна корпорация, один инит, один фюрер, то есть, простите, поттеринг.
> Это ваше утверждение наглядно показывает, что вы ничего не понимаете в юниксвее
> :)http://ru.wikipedia.org/wiki/п╓п╦п╩п╬я│п╬я└п╦я▐_UNIX#.D0.9C.D0.B0.D0.BA.D0.98.D0.BB.D1.80.D0.BE.D0.B9:_.D0.A7.D0.B5.D1.82.D0.B2.D0.B5.D1.80.D1.82.D1.8C_.D0.B2.D0.B5.D0.BA.D0.B0_UNIX
Просвещайтесь. Но я даже намекну, на что стоит особенно обратить внимание - "Делайте что-то одно, но делайте это хорошо"
> Зачем? Есть же базовая система.
А зачем в systemd просматривалка/убивалка процессов (для cgroups), кастрированный LXC, песочницы, syslog, cron'о-заменитель и куча ещё всего?
> Это примерно то же самое.
Неа. Systemd - огромный монолит. Не в плане реализации (понятно, что оно модульное), а в плане идеологии. Systemd написан так, чтобы после перехода на него его было крайне сложно выпилить. В отличие от базовой системы, которую можно переколбасить как угодно.
>> Что касается курения матчасти, ок, скинь ка мне, где, кроме бреда гаррипоттеринга написано, что базовая система, содержащая более одного бинарника - это юниксвей?
> fixedЭто ты где такое видел оО?
> Для этого inetd должен запускать в самом начале загрузки (даже раньше syslog),
> и непрерывно работать до полного выключения (даже без права на перезапуск,
> иначе накроются все программы, запущенные через сокет-активацию). Юниксвейненький у вас
> inetd получился, нечего сказать :)Мы кажется говорили о разных вещах. Я не это имел ввиду. Наверное не так понял, я говорил о следующей функции systemd: если сервис падает, то оно пишет все данные, которые приходят на порт в буфер и передаёт их потом восстановленной программе. Или что-то типо того, я не помню уже.
А то, про что ты говоришь у меня в своё время пролетело мимо ушей, я не знаю об этом ничего ни в контексте systemd, ни в контексте launchd.
Ссылка на википедию побилась. Ссылался на статью "Философия UNIX".
> А зачем в systemd просматривалка/убивалка процессов (для cgroups),чо-чо? cgroups нужны для управления ресурсами
>кастрированный LXC,
что вы этой фразой хотите сказать? lxc - это в ядре.
> Что-то нынче во всех свободных никсах начали выкидывать старые системы init, и
> писать с нуля новые.Во FreeBSD init не управляет демонами, и его никто не трогает.
> так как лог сохраняется локально, злоумышленнику не составляет труда ... почистить в нём следы своей деятельностиНа самом деле не все так просто. В UNIX (включая Фрю) логи аудита хранятся в довольно хитром бинарном формате.
Из простых вариантов - удалить. Но это сразу наводит администратора на соответствующие мысли.
Ну ведь не так сложно написать приложеньице, которое в этом формате может покопаться и удалить нужные записи ;-) Фундаментальная проблема в том, что, если удалось рутануть тачку, формат уже не имеет такого большого значения.
Не спорю. Но редактор для логов аудита - это дополнительный гемор взломщику. Не всякий кидди осилит, согласитесь.
> Не всякий кидди осилитБлин, а получить доступ к системе каждый? Учитывая что формат логов узнать можно без особых проблем.
> Блин, а получить доступ к системе каждый?Учитывая, что критические дыры в базовой системе оставляют незакрытыми по полгода - не так уж и сложно.
>> Блин, а получить доступ к системе каждый?
> Учитывая, что критические дыры в базовой системе оставляют незакрытыми по полгода -
> не так уж и сложно.у тебя же уже есть список с over 9000 порутанными хостами, правда? дай плиз шеллы на сервера из .ua и .ca, хочется для счастья иметь там "свой" хост.
Ничего хитрого в этом формате нет. Он был сделан таким исключительно для ускорения работы всей системы аудита. И для ускорения запросов к журнала аудита.
> В настоящее время все усилия разработчиков направлены на обеспечение сборки и запуска всей системы FreeBSD с использованием ClangВот оказывается главное направление разработки: чтоб не на gcc.
>> В настоящее время все усилия разработчиков направлены на обеспечение сборки и запуска всей системы FreeBSD с использованием Clang
> Вот оказывается главное направление разработки: чтоб не на gcc.Ну правильно. Новый gcc импортировать в базу нельзя, а новых фич и поддержку новых процессоров получить хочется.
А не далее как в пятницу суровый мущина Mitsuru IWASAKI реализовал таки для фряхи suspend/resume для smp, в том числе для конфигураций с nvidia-driver. Вот это настоящий прорыв, вот этого ждали многие. Засыпание/просыпание было уже во всех осях, кроме фряхи (было РАБОЧЕЕ), теперь вот и у нас будет.
Слава FreeBSD, только Беркли, только академичность, только хардкор!
Что интересно, таки засыпала 8.2 с nvidia нормально (и просыпалась:). Но это, скорее, частный случай.
До этого момента я не видел ни одной аппаратной платформы, которая на фряхе могла бы заснуть и проснутся. А через меня проходят десятки ноутбуков - ни один. Засыпают то многие, а вот не просыпается ни один.
Так было до прошлой пятницы.
Да-да, вы про это? http://lists.freebsd.org/pipermail/freebsd-current/2012-May/...P.S. Был тут один Acer. Там было 8.2-STABLE amd64. С кастомным ведром (просто вырезаны всякие рейды, не более). И таки он засыпал/просыпался из KDE'шного гуя. А вот с 9.0-RELEASE i386 GENERIC ни фига не просыпался. Так что всё же это исключение из правил было на тот момент.
Он писал про "[CFT] SMP/i386 suspend/resume". i386 - ключевое слово. И, как он сам писал, он портировал это из amd64, а значит там оно работало и раньше
> А не далее как в пятницу суровый мущина Mitsuru IWASAKI реализовал таки
> для фряхи suspend/resume для smp, в том числе для конфигураций с
> nvidia-driver. Вот это настоящий прорыв, вот этого ждали многие. Засыпание/просыпание
> было уже во всех осях, кроме фряхи (было РАБОЧЕЕ), теперь вот
> и у нас будет.
> Слава FreeBSD, только Беркли, только академичность, только хардкор!для (внимание) i386 SMP
Сейчас в зоне 51
kde-4.8.3,
Calligra 2.4.1 не собирается, 2.3.87 собиралась но глючила,
2.4.0 потеряли текстовый редактор.
> Сейчас в зоне 51
> kde-4.8.3,
> Calligra 2.4.1 не собирается, 2.3.87 собиралась но глючила,
> 2.4.0 потеряли текстовый
> редактор.вы не туда написали отчет.
сюда нужно посмотреть нет ли уже подобного отчета http://www.freebsd.org/cgi/query-pr-summary.cgi?category=&se...если нет - то нужно оформить тут http://www.freebsd.org/send-pr.html с подробным описание проблемы...
Неее, это только информация к размышлению.
Товарисчи в курсе.
Товарисчи исправились Calligra 2.4.1 собралось
и даже работает.
> Calligra 2.4.1 не собирается, 2.3.87 собиралась но глючила,
> 2.4.0 потеряли текстовый редактор.То ли еще будет. Даешь локальный гццкапец. Пусть бсдшники таки насладятся желаемыми ими свободами. Хочу на это посмотреть.
Чего будет?
Зона51 и не такое бывает,
это для таких как я, жутко продвинутых ;)
ДА!! GCC в массы - Clang людям.
>В базовую систему FreeBSD 10.0-CURRENT и 9.0-STABLE по умолчанию установлен распространяемый под лицензией BSD компилятор Clang 3.0Ну все. Теперь это оффициальный тестовый полигон Apple для MacOS.
> Ну все. Теперь это оффициальный тестовый полигон Apple для MacOS.Всегда так было. Вы только сейчас это для себя открыли?
Лучше бы Napierala допилил RCTL, aka Resource Containers.
> Лучше бы Napierala допилил RCTL, aka Resource Containers.Нет денег - нет любви.
Деньги как раз есть, там грант на это дали по GSoC
>Во FreeBSD/arm отмечается прогресс поддержки SoC компании Texas Instruments, таких как OMAP3, OMAP4 и AM335x.а зачем?
>> OMAP3, OMAP4 и AM335x.
> а зачем?А чтобы на момент снятия с производства чипа как раз поддержку заявить. Только хардкор же, так что как раз самое оно - зарелизить поддержку чипа в день объявления EoL :)
>>> OMAP3, OMAP4 и AM335x.
>> а зачем?
> А чтобы на момент снятия с производства чипа как раз поддержку заявить.не, я вполне серьёзно. оно же без поддержки dsp на этих чипах смысла не имеет.
По поводу bsdsort - оно _уже_ устанавливается по умолчанию как bsdsort. Это поведение можно изменить опцией WITH_BSD_SORT=yes в make.conf. В данном случае bsdsort установится как sort, а GNU sort установится как gnusort.
FSC... SMF...
Я дождался. Ща заплачу...
Если вписать строчки: WITHOUT_BINUTILS=true и WITHOUT_GCC=true в /etc/src.conf FreeBSD 9-STABLE, то базовая система и ядро собираются системным LLVM/Clang на 15 минут быстрее (~1 ч 15 минут вместо ~1 ч 30 минут). Однако при инсталляции ядра выкакивает ошибка, связанная с библиотекой libc++.so и не удаётся в таком виде инсталлировать ядро и систему.Вообще, скорее бы из базовой системы удалили весь ненужный "крап" типа GCC, SENDMAIL, BIND.
>весь ненужный "крап"это как раз порты. в этом плане debian/kfreebsd наиболее правильно двигается.
> ядра выкакивает ошибкаопечатка понравилась
>> ядра выкакивает ошибка
> опечатка понравиласьМне тоже. Не стал исправлять.
Дык пофикси, ты ж якобы опытный джавист
>>Во FreeBSD 10.0-RELEASE принято решение задействовать Clang в качестве системного компилятора по умолчаниюКаковы причины, расскажите кто знает
>>>Во FreeBSD 10.0-RELEASE принято решение задействовать Clang в качестве системного компилятора по умолчанию
> Каковы причины, расскажите кто знаетGPLv3
>>>Во FreeBSD 10.0-RELEASE принято решение задействовать Clang в качестве системного компилятора по умолчанию
> Каковы причины, расскажите кто знает1. Невозможность внести в базовую систему код современных версий GCC и осуществлять адекватную поддержку этого кода.
2. LLVM/Clang — современная система компиляции, которая жёстко придерживается стандартов на языки программирования C и C++. Имеет адекватное качество кодогенерации и позволяет задействовать различные механизмы анализа кода и JIT-компиляции в промежуточный код, независимый от целевой платформы. NVIDIA CUDA для GPU уже развивается в рамках субпроекта LLVM.
> 1. Невозможность внести в базовую систему код современных версий GCC и осуществлятьНу прям. За 5 лет расхождений конечно уже сложно, но отнюдь не невозможно, если бы было такое желание.
>> 1. Невозможность внести в базовую систему код современных версий GCC и осуществлять
> Ну прям. За 5 лет расхождений конечно уже сложно, но отнюдь не невозможно, если бы было такое желание.GNU — GNU Not Unix. GCC — это порождение чуждой идеологии не-Unix, которая стремится переписать всё программное обеспечение Unix по-другому. LLVM/Clang — это, в некоторой степени, замена не-Unix на Unix-компилятор. Тоже и с остальным "добром" от переписываетелей Unix из GNU — выбросить без зазрения совести. Написать своё "BSD", возродить настоящий Unix в качестве СИСТЕМЫ.
>>> 1. Невозможность внести в базовую систему код современных версий GCC и осуществлять
>> Ну прям. За 5 лет расхождений конечно уже сложно, но отнюдь не невозможно, если бы было такое желание.
> GNU — GNU Not Unix. GCC — это порождение чуждой идеологии не-Unix,
> которая стремится переписать всё программное обеспечение Unix по-другому. LLVM/Clang
> — это, в некоторой степени, замена не-Unix на Unix-компилятор. Тоже и
> с остальным "добром" от переписываетелей Unix из GNU — выбросить без
> зазрения совести. Написать своё "BSD", возродить настоящий Unix в качестве СИСТЕМЫ.Только BSD, только Unix, только хардкор!
> GNU — GNU Not Unix. GCC — это порождение чуждой идеологии не-Unix,
> которая стремится переписать всё программное обеспечение Unix по-другому.а что, Unix - это хорошо? это окаменевшее ископаемое.
Юних - это просто отлично. Тем более, что он не окаменевший, и не ископаемый. А что он консервативен - так это следствие хорошего дизайна и здравого подхода к развитию. Тем он и хорош.
>Тем более, что он не окаменевший, и не ископаемый. А что он консервативен - так это следствие хорошего дизайна и здравого подхода к развитию.ноу проблем. тогда выкиньте kqueue/epoll и используйте select/poll. потому что в unix этого нет.
> тогда выкиньте kqueue/epoll и используйте select/poll. потому что в unix этого нет.Фря, друг мой, не есть юних. Она всего лишь юних-компатибле. Даже, если быть точным, посих-компатибле. Вне рамок посиха фря может принимать самые разнообразные и причудливые формы. Впрочем, если б она на все 100% соответствовала АТ/Т юниху, вы бы немедленно заявили про ископаемую окаменелость, верно?
>> тогда выкиньте kqueue/epoll и используйте select/poll. потому что в unix этого нет.
> Фря, друг мой, не есть юних.1)я вам не друг. мы с вами не пили
2)речь не о фре. а о unix.
3)говорящие, что unix - это тру, забывают о том, что в unix не было многих вещей, без которых современный хайлоад невозможен. в кач-ве примера я привёл kqueue/epoll
> Она всего лишь юних-компатибле. Даже, если
> быть точным, посих-компатибле. Вне рамок посиха фря может принимать самые разнообразные
> и причудливые формы.windows тоже соответствует posix.
> Впрочем, если б она на все 100% соответствовала
> АТ/Т юниху, вы бы немедленно заявили про ископаемую окаменелость, верно?понимаете, самолёт братьев Райт открыл эру авиастроения. но это не значит, что стоит им восхищаться сейчас.
> а что, Unix - это хорошо? это окаменевшее ископаемое.Хех. Живет десяток лет, работает. Что еще для счастья надо? Поставил 10 лет назад - и забыл. И это - правильно. Неправильно накатывать апдэйты раз в месяц и тяжко маяться, восстанавливая работоспособность системы.
>>> 1. Невозможность внести в базовую систему код современных версий GCC и осуществлять
>> Ну прям. За 5 лет расхождений конечно уже сложно, но отнюдь не невозможно, если бы было такое желание.
> GNU — GNU Not Unix. GCC — это порождение чуждой идеологии не-UnixДа-а-а-а-а. Пожалуй, наступил момент, когда во FreeBSD полезли
такие же тупые фанатики, какие сейчас лезут в Линупс. Ужас :-(
WITHOUT_GCC=true в /etc/src.conf во вновь собранной и установленной FreeBSD 9-STABLE после команды: "cd /usr/src/ && make BATCH_DELETE_OLD_FILES=true delete-old delete-old-libs" удаляет ошмётки GCC из системы.Опции:
WITH_CLANG=true
WITH_CLANG_IS_CC=true
в /etc/src.conf в процессе установки вновь собранной системы делают системным компилятором по умолчанию Clang.
> URL: http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdconfig/
> Approaching 20,000 lines of sh(1) code, the bsdconfig(8) tool is approximately 70% complete.20 тыщ строк кода на ШЕЛЛЕ, лежащего в древнючем *CVS*, и всё это - друидБСД. Название у этих древофилов точно отражает содержание. Получится робот класса "Буратино", однозначно.
Нет, бл..дь.. нужно впендюрить православный питон в базовую систему или вые..ться на С/С++. Извиняйте. В BSD Поттерингов нет и не будет к счастью в обозримом будущем.
При правильной архитектуре кода 20000 строк на шелле не так уж и много.
>При правильной архитектуре кода 20000 строк на шелле не так уж и много.KISS сморит на тебя как на ....
20КLOC - это много на любом языке. Да - даже на асме.
Ядро Линукс смотрит на тебя как на..
#>> 20000 строк на шелле не так уж и много.> Ядро Линукс смотрит на тебя как на..
"shell script 11,010 ... 17,458". Ви же таки про шелл? http://www.ohloh.net/p/linux/analyses/latest
> "shell script 11,010 ... 17,458". Ви же таки про шелл? http://www.ohloh.net/p/linux/analyses/latestЧто сказать-то хотели? Или как обычно, пердеж в лужу?.
Для любящих выдирать фразы из контекста и передергивать повторюсь: При нормальной архитектуре 20k строк кода не такая уж и проблема даже на Шелле.
> Что сказать-то хотели? Или как обычно, пердеж в лужу?.
> Для любящих выдирать фразы из контекста и передергивать повторюсь: При нормальной архитектуре
> 20k строк кода не такая уж и проблема даже на Шелле.Ну,как... 20Кстрок _шела там нету. Поэтому на "нормальную архитектуру" не претендует. Повторите поытку! Музыка и лужа.
Да оставь - это же секс инструктор теоретик :) Сам ни строчки кода ессно не написавщий :)
Даже не видит что кроме него гениального никто и не подумывает назвать ведро "не так уж и много". Много это и сложно. Но для тех кто реально работает, для перца - понятное дело раз ширинку рсасстегнуть :)
:-D Улыбнуло. Спасибо.
> Нет, бл..дь.. нужно впендюрить православный питон в базовую систему или вые..ться на
> С/С++. Извиняйте.может, всё-таки стоит выбрать более подходящий инструмент, чем shell?
>В BSD Поттерингов нет и не будет к счастьюа что такого плохого Поттеринг сделал? тот же pulseaudio прекрасен.
> может, всё-таки стоит выбрать более подходящий инструмент, чем shell?Все-таки загляните в исходники. Код организован так, что затраты на его поддержку и развитие будут не выше чем у того же C или Питона.
>>В BSD Поттерингов нет и не будет к счастью
> а что такого плохого Поттеринг сделал? тот же pulseaudio прекрасен.Прекрасен OSS
>> может, всё-таки стоит выбрать более подходящий инструмент, чем shell?
> Все-таки загляните в исходники. Код организован так, что затраты на его поддержку
> и развитие будут не выше чем у того же C или
> Питона.понимаете, можно и на php писать поддерживаемый код. только надо держать в голове сотни особенностей, неочевидных вещей итп.
>>>В BSD Поттерингов нет и не будет к счастью
>> а что такого плохого Поттеринг сделал? тот же pulseaudio прекрасен.
> Прекрасен OSSи как в этой прекрасной OSS прозрачно перенести проигрывание звуков на удалённую машину?
> и как в этой прекрасной OSS прозрачно перенести проигрывание звуков на удалённую машину?Это задача приложений и протоколов прикладного уровня. Разве нет?
>> и как в этой прекрасной OSS прозрачно перенести проигрывание звуков на удалённую машину?
> Это задача приложений и протоколов прикладного уровня. Разве нет?Изя, если твоя фирма получит контракт на пару сотен млн $ и указывая на один из этапов его выполнения скажешь "это не наша задача. мы это не умеем" или же всё-таки найдёшь подрядчика?
вот пульсаудио умеет и по сети, и per application уровни и источники записи/воспроизведения и чёрта в ступе.
Вообщем, вам шашечки или же ехать?
> а что такого плохого Поттеринг сделал? тот же pulseaudio прекрасен.А ты не его жена сучайно? А то вам одни и те же извраты нравятся ....
>> а что такого плохого Поттеринг сделал? тот же pulseaudio прекрасен.
> А ты не его жена сучайно? А то вам одни и те
> же извраты нравятся ....Простите, вы путаете меня с Маккузиком и Оллманом. Это в *BSD гордятся гей-культурой.
>>> а что такого плохого Поттеринг сделал? тот же pulseaudio прекрасен.
>> А ты не его жена сучайно? А то вам одни и те
>> же извраты нравятся ....
> Простите, вы путаете меня с Маккузиком и Оллманом. Это в *BSD гордятся
> гей-культурой.ты за всех не отвечай....
> может, всё-таки стоит выбрать более подходящий инструмент, чем shell?java в base неистово нужна, да!
ну или, накрайняк, быдлопитон.
или что есть "более подходящий инструмент"?
>> может, всё-таки стоит выбрать более подходящий инструмент, чем shell?
> java в base неистово нужна, да!а чо, энтерпрайзно =))
> ну или, накрайняк, быдлопитон.
> или что есть "более подходящий инструмент"?так брейнфак. вроде ж где-то уже писал =)
>>> может, всё-таки стоит выбрать более подходящий инструмент, чем shell?
>> java в base неистово нужна, да!
> а чо, энтерпрайзно =))
>> ну или, накрайняк, быдлопитон.
>> или что есть "более подходящий инструмент"?
> так брейнфак. вроде ж где-то уже писал =)его и жавы нет из коробки даже в этих твоих гламурных линуксах, что меня, например, удивляет. петон, перд, эрланк и еще какой-то ужос ставится, брейнфак почему-то нет (я про дебилиан и "минимальную" установку)
На Си будет неудобно для возможных дистроклепателей, а bsdconfig то, что будет с большой вероятностью ими меняться.
>ожидается, что размер кода bsdconfig составит приблизительно 20 тысяч строк на shellHoly shit!
Очень я переживаю за "развод по итальянски" Фряхи и GCCя :(
Хрен его знает что там с этим шлангом ещё выйдет ...
gcc при желании возвращается одной строкой.
> gcc при желании возвращается одной строкой.Оно то так ... но со временем "пркладного бубнобиения" будет всё больше. Возми последий жисиси - установи как сисемный пересобери ялро и мир. Оппа! _уже_ ручки надо прилагать. А в перспективе ... FreeBSD community << Linux one - Боливар два компилятора может и не вытащить. И это реально грустно :(
> Боливар два компилятора может и не вытащить. И это реально грустно :(Многие разработчики переходят на использование LLVM/Clang в качестве компилятора для процесса отладки, а GCC используется только лишь для целевой (окончательной) компиляции.
Это о чём говорит? О том, что GCC используется только для оптимизации готового кода, но уже не для процесса разработки.Когда LLVM/Clang достигнет того же качества оптимизации результирующего кода (а до этого уже не так долго осталось, так как Clang отлаживается совместно с написанием приложений), то GCC будет удерживать свою позицию только благодаря широкому спектру поддерживаемых архитектур. И то — недолго.
>Многие разработчики переходят на использование LLVM/Clang в качестве компилятора для процесса отладки, а GCC используется только лишь для целевой (окончательной) компиляции.это голоса в вашей голове такое говорят? или же есть реальные не единичные примеры?
>>Многие разработчики переходят
> это голоса в вашей голове такое говорят?--А Динамо бежит? --Все бегут!!!%-Q
>>Многие разработчики переходят на использование LLVM/Clang в качестве компилятора для процесса отладки, а GCC используется только лишь для целевой (окончательной) компиляции.
> это голоса в вашей голове такое говорят? или же есть реальные не
> единичные примеры?Рагусь, именно реальный и не единичный.
> Рагусь, именно реальный и не единичный.конкретика где?
> есть реальные не единичные примеры?Следите за новостями на OpenNet.ru.
>> есть реальные не единичные примеры?
> Следите за новостями на OpenNet.ru.Изя, слежу. Но все те же лица: juniper, ixsystems...
развод был давно. а сегодня так - допинывают остатки.
Что такое стек С++? Вапче не понял о чем...
На плюсах будут переписывать все сишное? Так это ж чмошный язык для чмошников