Разработчики проекта Debian GNU/Linux опубликовали отчет (http://lists.debian.org/debian-devel-announce/2010/02/msg000...) о состоянии подготовки будущего релиза Debian 6.0 (Squeeze), в котором упоминается о слишком большом числе блокирующих релиз критических ошибок (http://bugs.debian.org/release-critical/). В настоящий момент число критических ошибок составляет 1030, в прошлые релизы заморозка пакетной базы производилась после снижения числа таких ошибок как минимум до 300.
Тем не менее разработчики все еще надеются успеть выполнить заморозку кода в марте. В качестве одного из способов решения возникшего тупика рассматривается возможность введения драконовских мер, в соответствие с которыми из состава ветки "testing" будут удалены пакеты в которых отмечаются неисправленные мантейнерами критические ошибки.
Напомню, что в соответствии с планом (http://www.opennet.me/opennews/art.shtml?num=22794) по введению фиксированного по времени графика подготовки релизов, заморозка ...URL: http://lists.debian.org/debian-devel-announce/2010/02/msg000...
Новость: http://www.opennet.me/opennews/art.shtml?num=25352
> Полная поддержка IPv6 (поддержка IPv6 во всех приложениях которые могут работать через IPv4);и что? даже в "Psi" ? (instant messenger)
и в "lwp-request" ?
... ну прям невериться :-) .. на Psi у меня надежды точно нет
Как определить - задействован KMS или нет?
> Переход на использование для выполнения shell скриптов вместо /bin/sh быстрой и упрощенной оболочки dashПоясните. /bin/sh давно не бинарник, а симлинк на что-то, например bash. Перенаправляем на dash и всё, так?
dash не поддерживает всего функционала bash, поэтому некоторые скрипты не будут работать.
Кому тогда этот dash вообще нужен, регрессия - не наш метод
>Кому тогда этот dash вообще нужен, регрессия - не наш методdash требует меньше ресурсов, быстрее работает.
bash без readline и прочих интерактивных фич не судьба была собрать или всё же бенчили?PS: dash глючный, напарывались тут...
>Кому тогда этот dash вообще нужен, регрессия - не наш методДля ускорения запуска скриптов инициализации.
> Кому тогда этот dash вообще нужен, регрессия - не наш методверно, регрессия (может быть) ..
..а причина регресии? разумеется не замена /bin/sh на dash !
...а то что -- <КТОТО> (ктото нехороший) когда писал скрипты на /bin/sh -- не сверился с общепринятыми нормами .
....а если сверился и СПЕЦАИЛЬНО их решил нарушить (для пущщего использования функциональности) , то тогда могбы подставить в качестве интерпретатора -- напрямую #!/usr/bin/env bash , а не /bin/sh
****************************************
ровно точно также как и разработчики php-сайтов, которые делают сайты работающщие на Apache но не работающие на Nginx .
а потомучто есть принцеп (на которые НЕ нада плeвать) :
если делаешь какойто скрипт, то будь добр использовать НЕ СПЕЦИФИЧЕСКИЕ конструкции для взаимозаменяемых компонентов стека на котором предназначен работать разрабатываемый скрипт...
где можно посмотреть эти общепринятые стандарты?
POSIX.2
> где можно посмотреть эти общепринятые стандарты?google: posix shell
Это как раз не регрессия. Регрессия - это использование в скриптах башизмов (показательно, что есть даже специальный термин).
>Кому тогда этот dash вообще нужен, регрессия - не наш методЯ не понял: если вы указываете в скрипте интерпретатором именно bash - пользуйтесь его расширенным функционалом наздоровье. И или будет работать или юзер поймет что интерпретера нет. А если вы указали /bin/sh, то какого хрена вы вообще возомнили что это всенепременно обязан быть bash вообще и что можно пользоваться чем-то из расширений? Только потому что есть 2 мнения - ваше и неправильное? Итого если и вылезут регрессии, единственное что они покажут, кто из авторов скриптов - тормоз который не включает мозг при написании своего добра, считая свою конфигу единственно существующей и единственно правильной. Лучше пусть сразу rm запускает, на своей машине, одним дятлом меньше будет :)
>Итого если и вылезут регрессии, единственное что они покажут [...]Ну-ну. Скажем, ноябрь прошлого года...
<mike> привет! проверяю один скрипт на работу с ash -- обнаружилась разница в поведении с bash: read a b при наличии нескольких символов из $IFS подряд (табов в /proc/cpuinfo в данном разе) отбрасывает только один, а остальные клеит в b. bash делает то, что и ожидается -- последовательность разделителей воспринимает как один разделитель
<mike> это как-то регулируется, или что в таких случаях положено делать для портабельных скриптов?
[...]
<legion> это бага в dash
<legion> и она почти исправленаPS: Вы не пытались рефакторить и компрессировать свои постинги?
> <legion> это бага в dashНапугали тестера багами :). Вы хотите сказать что в bash багов нет? Учтя его размеры и навернутость - я бы зуб за это не дал. А то что bash больше используют и потому очевидные баги вытоптали - ага. Ну и в dash вытопчут.
Зато если на чем-то с слабым процом (handhelds, embedded) поюзать баш - сразу станет понятно насколько он монструозен и тормознут. Он стартует очень не быстро и его замена на что-то более легкое дает заметный на глаз результат. Да и на десктопах и серверах заметно там где много вызовов шелла за короткое время.
>PS: Вы не пытались рефакторить и компрессировать свои постинги?
Боюсь форумный движок не оценит по достоинству вывод гзипа :P. А насчет рефакторинга - это надо стиль мышления несколько перестроить.
>> <legion> это бага в dash
>Напугали тестера багами :)То есть пользователи dash -- заведомо тестеры? Как страшно жить. :)
>Вы хотите сказать что в bash багов нет?
Я хочу сказать, что не всякая регрессия при переходе с sh на dash -- обязательно неадекватность разработчика скрипта.
>Ну и в dash вытопчут.
Надеюсь. :)
>Зато если на чем-то с слабым процом (handhelds, embedded) поюзать баш -
>сразу станет понятно насколько он монструозен и тормознут.Будет под рукой альт -- посмотрите через прицел time и ldd на тамошний /bin/sh. Ну или сюда, по вкусу:
http://git.altlinux.org/people/ldv/packages/?p=bash.git;a=bl...Сделано именно с целью ускорения запуска скриптов.
>>PS: Вы не пытались рефакторить и компрессировать свои постинги?
>Боюсь форумный движок не оценит по достоинству вывод гзипа :P.Существуют разные методы {с,от}жатия. :)
>А насчет рефакторинга - это надо стиль мышления несколько перестроить.
Мне порой помогает перечитывать перед отправкой насчёт лишних слов; также суть удобней воспринимать, если она не завалена каждый раз изрядным куском общего контекста (который можно оформить и полировать на вики, чтоб #include'ить).
>То есть пользователи dash -- заведомо тестеры? Как страшно жить. :)Нет, я только за себя говорю. Не надо экстраполировать на всех :P. Если развить мысль - я не против побыть в тестерах если результат усилий мне потенциально интересен. Усконение загрузки системы и улучшение работы скриптов мне в принципе потенциально итересны.
>Я хочу сказать, что не всякая регрессия при переходе с sh на
>dash -- обязательно неадекватность разработчика скрипта.Я имел в виду что если некто юзал башизмы в скрипте а дергал /bin/sh наивно полагая что это был всенепременно bash - он птичкадятел. И именно такое в основном и ломается когда /bin/sh указывает на что-то иное.
>Надеюсь. :)
Куда ж они денутся?
>Будет под рукой альт -- посмотрите через прицел time и ldd на
>тамошний /bin/sh.Debian всерьез предлагается как дистр для некоторых ARMовских железок. Поэтому могу себе представить что дебианщиков скорость интерпретера команд - волнует. На каком-нить NAS с 200 мгц процом все более уныло чем на PC, поэтому - да, на чем-то таком я бы поразвлекался time-ом т.к. это имеет смысл. Но у меня нет подходящего девайса а альт вообще для ARMов вроде не существует. И кстати достаточно разные шаблоны использования - на PC скажем могут нечто компилить и вес скорости выполнения скрипта vs скорости старта интерпретера могут быть различны по своей проблемности. Так что кого там и как бенчить достаточно непростой вопрос.
Ну или сюда, по вкусу:
>http://git.altlinux.org/people/ldv/packages/?p=bash.git;a=bl...
>h=5dbdb990f11860b5dfd507aeef8bd959661b33e5;hb=HEAD#l148
>Сделано именно с целью ускорения запуска скриптов.Я так понимаю что вы обкусили там кой-чего на этапе компила. Даже хелпарь. Я так понимаю - соль в этом? Да, в таком виде было бы интересно сравить но пока не очень понятно как делать честное сравнение нигде не облажавшись. Для sh-образных есть какие-то бенчмарки? :)
>Существуют разные методы {с,от}жатия. :)
"Крткст сстр тлнт"? :)
>(который можно оформить и полировать на вики, чтоб #include'ить).
Интересная мысль. В ней что-то есть.
>Но у меня нет подходящего девайсаТут народ sheeva plug'и набирает, btw.
>а альт вообще для ARMов вроде не существует.
Неофициальный экспериментальный порт доступен (см. вики, здесь уж совсем офтопик).
>>Сделано именно с целью ускорения запуска скриптов.
>Я так понимаю что вы обкусили там кой-чего на этапе компила.
>Даже хелпарь. Я так понимаю - соль в этом?Угу. Но при этом в сухом остатке всё равно заведомо обтоптанный bash.
>Да, в таком виде было бы интересно сравить но пока не очень понятно как
>делать честное сравнение нигде не облажавшись. Для sh-образных есть какие-то бенчмарки?
>:)Сходу не припомню, сам думал поискать что-то вроде debian bash das default benchmark.
>>Существуют разные методы {с,от}жатия. :)
>"Крткст сстр тлнт"? :)Кр. -- сестр. тал. (а не древнеивритский :)
При чём здесь bash, когда речь о sh?
> Поясните. /bin/sh давно не бинарник, а симлинк на что-то, например bash.верно! при этом bash (запущенный как симлинк /bin/sh ) -- переводиться в ДРУГОЙ РЕЖИМ своей работы . "упрощённый" режим .
...однако даже в "упрощённом режиме" -- bash тратит ресурсов [повидимому] больше чем [родной режим] dash , что лигично вобщемто
OSS зря обидели
32е ядро? Дебиан? что-то в этой вселенной вывернулось наизнанку...
Просто 32е ядро долгой поддержки. :)
Зато все железо без танцев с бубном подхватывается сразу, за исключением wifi карточек, которым нужна прошивка.
>Зато все железо без танцев с бубном подхватывается сразу, за исключением wifi
>карточек, которым нужна прошивка.Не, я знаю чем это хорошо, и чем плохо, просто это для дебиан стейбл совсем не свойственно...
Небось они это ядро теперь ближайшие 5ть лет будут держать...
Ведь его сам Линус похвалил -:)
А dom0 ядра выкинули почему? теперь ручками собираем или теперь новые ядра сразу умеют dom0 из коробки (как domU) ?
Собирать ручками, или сидеть на lenny, или съезжать на другой дистр.
>А dom0 ядра выкинули почему?Ну, как... Все были уверены, что _Debian медленно релизит, но оказалось, что lenny вышел _слишком быстро для "оставшихся" в районе 2.4.18(?) апстримов Xen-а и "не успевших" за не то что Торвальдс&ко, но даже за релизом Debian........................
http:/openforum/vsluhforumID15/2213.html#1
Уже-всё-ещё и к выходу squeeze-а "не поспевают". Во всём виноват Торвальдс?
>теперь ручками собираем или теперь новые ядра сразу умеют dom0 из коробки (как domU) ?
http://wiki.debian.org/Xen, http://wiki.debian.org/DebianRussian/Xen
>в районе 2.4.18(?)Вы ничего не перепутали? Это ядро вышло когда Xen еще в проекте не было... oO
>>в районе 2.4.18(?)
>Вы ничего не перепутали?Конечно. 2._6_.18.
Поскорей бы уже заморозили. На одном сервачке стоит squeeze и иногда приносит неприятные косяки при обновлении. Stable решает.
вот ПОЭТОМУ и не стоит морозить РАНЬШЕ ВРЕМЕНИ.
ибо ИМЕННО ЭТО отличает stable от unstable. и Debian - от остальных дистрибутивов. помимо положенной в край угла GNU-концепции.
IMHO, надо отложить пакеты "тормозящие" для бэкпортирования, из числа некритичных для дистра.
>вот ПОЭТОМУ и не стоит морозить РАНЬШЕ ВРЕМЕНИ.Угу, вот только когда какойнить нужный позарез софт не соберется из-за древних либ а пересобирать два вагона либ заломает - вот тут то и поймешь что stable это хорошо, но не всегда. Из-за этого я на некоторых серверах юзаю серверную убунту. Те же яйца, вид в профиль, но софт и либы куда актуальнее. Каких-то крупных отвалов башки не наблюдал вроде.
>>вот ПОЭТОМУ и не стоит морозить РАНЬШЕ ВРЕМЕНИ.
>
>Угу, вот только когда какойнить нужный позарез софт не соберется из-за древних
>либ а пересобирать два вагона либ заломает - вот тут то
>и поймешь что stable это хорошо, но не всегда. Из-за этого
>я на некоторых серверах юзаю серверную убунту. Те же яйца, вид
>в профиль, но софт и либы куда актуальнее. Каких-то крупных отвалов
>башки не наблюдал вроде."вроде" не приемлемо для практического применения в business dataflow/docflow. если что-то хотя бы ПОТЕНЦИАЛЬНО, компромайзит целостность-секьюрность информационной системы - вопросы отпадают. cм дефиниции RHEL-строения или подход Debian к тестированию.
либо стабильность есть, либо ее нет.
и тут ПРИХОДИТСЯ выбирать, что Важнее - cтабильность или мешки софта.
RHEL[CentOS]/Debian Stable/Slackware или Fedora обезображенная коммандой Тимура-Шартллворта sid-Ubuntu-а или всякие гламурные Sybayon-ы с Mandriva-ой.
>"вроде" не приемлемо для практического применения в business dataflow/docflow.Понимаете, в любом сложном софте априори есть куча багов. И весь вопрос - в том будут ли они мещаться вам в вашей конфигурации с вашими задачами или нет. Какие-то глобальные отличия между убунтой и рхелом могут быть в качестве саппорта и скорости устранения багов. Но сие означает что вы уже вляпались, что вам не повезло, что флоу встал раком и т.п...
>если что-то хотя бы ПОТЕНЦИАЛЬНО, компромайзит целостность-секьюрность
>информационной системы - вопросы отпадают.Я вам гарантирую что оно потенциально есть в любой сложной системе. Вы там еще живой? Не умерли от разрыва сердца? Кстати да, дебиан вообще строго говоря без официальной коммерческой поддержки.Да, есть независимые спецы, но это все-таки не контора которая выпустила и оказывает поддержку.
>cм дефиниции
Вазап? Вы хотите рассказать тестеру о качестве софта? Хаха :)
>RHEL-строения или подход Debian к тестированию.
Да ладно вам, дерьмо случается у всех. У дебияна вон с нжинксом было прикольно в 4-й версии. Мало того что нереально античный нжинкс впаривался так еще и с поломанным скриптом деинсталла, после чего пришлось скурить ключи форса у dpkg и выносить кривой пакет заэнфорснув вообще все. А у центоса - таких ляпов я не видел но дерьмовость их пакетной системы и ее переколбасы вызывают желание держаться от этого барахла подальше и потому - я такие ляпы не больно то и искал. И софт там античный и его мало. Годится только для сильно замшелых. Да, в своей нише - выглядит нормально. Но современный софт юзать на таком - мучение полное.
>либо стабильность есть, либо ее нет.
Определение стабильности в студию. Только чур не путать с некромансией.
>и тут ПРИХОДИТСЯ выбирать, что Важнее - cтабильность или мешки софта.
Логично. А кирпич вообще может проваляться пару столетий без глюков. А то что софта под него нет - да и фиг с ним? И чем меньше софта - тем больше системник напоминает кирпич по степени бесполезности.
[бред заскипан]
Не знаю кто там что обезобразил но на практике серверная убунта работает. Грабель с ней не больше чем с дебианом, субъективно. Да и с фига ли быть иначе - тот же дебиан и есть, по сути.
хорошо бы заморозили с OpenOffice.org 3.2 и KDE 4.4