https://www.opennet.ru/openforum/vsluhforumID3/63734.html Разработчики проекта Debian GNU/Linux опубликовали отчет (http://lists.debian.org/debian-devel-announce/2010/02/msg00002.html) о состоянии подготовки будущего релиза Debian 6.0 (Squeeze), в котором упоминается о слишком большом числе блокирующих релиз критических ошибок (http://bugs.debian.org/release-critical/). В настоящий момент число критических ошибок составляет 1030, в прошлые релизы заморозка пакетной базы производилась после снижения числа таких ошибок как минимум до 300. <br><br><br>Тем не менее разработчики все еще надеются успеть выполнить заморозку кода в марте. В качестве одного из способов решения возникшего тупика рассматривается возможность введения драконовских мер, в соответствие с которыми из состава ветки "testing" будут удалены пакеты в которых отмечаются неисправленные мантейнерами критические ошибки. <br><br><br>Напомню, что в соответствии с планом (http://www.opennet.ru/opennews/art.shtml?num=22794) по введению фиксированного по времени графика подготовки релизов, заморозка ...<br><br>URL: http://lists.d https://www.opennet.ru/openforum/vsluhforumID3/63734.html#42 Mon, 15 Feb 2010 15:19:10 GMT &gt;&gt;в районе 2.4.18(?) <br>&gt;Вы ничего не перепутали?<br><br>Конечно. 2._6_.18.<br> https://www.opennet.ru/openforum/vsluhforumID3/63734.html#41 Mon, 15 Feb 2010 13:50:51 GMT хорошо бы заморозили с OpenOffice.org 3.2 и KDE 4.4<br> https://www.opennet.ru/openforum/vsluhforumID3/63734.html#40 Fri, 12 Feb 2010 18:51:27 GMT &gt;"вроде" не приемлемо для практического применения в business dataflow/docflow. <br><br>Понимаете, в любом сложном софте априори есть куча багов. И весь вопрос - в том будут ли они мещаться вам в вашей конфигурации с вашими задачами или нет. Какие-то глобальные отличия между убунтой и рхелом могут быть в качестве саппорта и скорости устранения багов. Но сие означает что вы уже вляпались, что вам не повезло, что флоу встал раком и т.п...<br><br>&gt;если что-то хотя бы ПОТЕНЦИАЛЬНО, компромайзит целостность-секьюрность <br>&gt;информационной системы - вопросы отпадают. <br><br>Я вам гарантирую что оно потенциально есть в любой сложной системе. Вы там еще живой? Не умерли от разрыва сердца? Кстати да, дебиан вообще строго говоря без официальной коммерческой поддержки.Да, есть независимые спецы, но это все-таки не контора которая выпустила и оказывает поддержку.<br><br>&gt;cм дефиниции <br><br>Вазап? Вы хотите рассказать тестеру о качестве софта? Хаха :)<br><br>&gt;RHEL-строения или подход Debian к тестированию. <br><br>Да ладно вам, дерьмо случается у всех. https://www.opennet.ru/openforum/vsluhforumID3/63734.html#39 Fri, 12 Feb 2010 17:50:46 GMT &gt;в районе 2.4.18(?) <br><br>Вы ничего не перепутали? Это ядро вышло когда Xen еще в проекте не было... oO<br> https://www.opennet.ru/openforum/vsluhforumID3/63734.html#38 Fri, 12 Feb 2010 14:35:14 GMT &gt;&gt;вот ПОЭТОМУ и не стоит морозить РАНЬШЕ ВРЕМЕНИ. <br>&gt;<br>&gt;Угу, вот только когда какойнить нужный позарез софт не соберется из-за древних <br>&gt;либ а пересобирать два вагона либ заломает - вот тут то <br>&gt;и поймешь что stable это хорошо, но не всегда. Из-за этого <br>&gt;я на некоторых серверах юзаю серверную убунту. Те же яйца, вид <br>&gt;в профиль, но софт и либы куда актуальнее. Каких-то крупных отвалов <br>&gt;башки не наблюдал вроде. <br><br>"вроде" не приемлемо для практического применения в business dataflow/docflow. если что-то хотя бы ПОТЕНЦИАЛЬНО, компромайзит целостность-секьюрность информационной системы - вопросы отпадают. cм дефиниции RHEL-строения или подход Debian к тестированию.<br>либо стабильность есть, либо ее нет.<br>и тут ПРИХОДИТСЯ выбирать, что Важнее - cтабильность или мешки софта.<br>RHEL[CentOS]/Debian Stable/Slackware или Fedora обезображенная коммандой Тимура-Шартллворта sid-Ubuntu-а или всякие гламурные Sybayon-ы с Mandriva-ой.<br> https://www.opennet.ru/openforum/vsluhforumID3/63734.html#37 Fri, 12 Feb 2010 14:00:38 GMT &gt;Но у меня нет подходящего девайса<br><br>Тут народ sheeva plug'и набирает, btw.<br><br>&gt;а альт вообще для ARMов вроде не существует.<br><br>Неофициальный экспериментальный порт доступен (см. вики, здесь уж совсем офтопик).<br><br>&gt;&gt;Сделано именно с целью ускорения запуска скриптов. <br>&gt;Я так понимаю что вы обкусили там кой-чего на этапе компила.<br>&gt;Даже хелпарь. Я так понимаю - соль в этом?<br><br>Угу. Но при этом в сухом остатке всё равно заведомо обтоптанный bash.<br><br>&gt;Да, в таком виде было бы интересно сравить но пока не очень понятно как <br>&gt;делать честное сравнение нигде не облажавшись. Для sh-образных есть какие-то бенчмарки? <br>&gt;:) <br><br>Сходу не припомню, сам думал поискать что-то вроде debian bash das default benchmark.<br><br>&gt;&gt;Существуют разные методы {с,от}жатия. :) <br>&gt;"Крткст сстр тлнт"? :)<br><br>Кр. -- сестр. тал. (а не древнеивритский :)<br> https://www.opennet.ru/openforum/vsluhforumID3/63734.html#36 Thu, 11 Feb 2010 20:20:31 GMT &gt;То есть пользователи dash -- заведомо тестеры? Как страшно жить. :) <br><br>Нет, я только за себя говорю. Не надо экстраполировать на всех :P. Если развить мысль - я не против побыть в тестерах если результат усилий мне потенциально интересен. Усконение загрузки системы и улучшение работы скриптов мне в принципе потенциально итересны.<br><br>&gt;Я хочу сказать, что не всякая регрессия при переходе с sh на <br>&gt;dash -- обязательно неадекватность разработчика скрипта. <br><br>Я имел в виду что если некто юзал башизмы в скрипте а дергал /bin/sh наивно полагая что это был всенепременно bash - он птичкадятел. И именно такое в основном и ломается когда /bin/sh указывает на что-то иное. <br><br>&gt;Надеюсь. :) <br><br>Куда ж они денутся? <br><br>&gt;Будет под рукой альт -- посмотрите через прицел time и ldd на <br>&gt;тамошний /bin/sh. <br><br>Debian всерьез предлагается как дистр для некоторых ARMовских железок. Поэтому могу себе представить что дебианщиков скорость интерпретера команд - волнует. На каком-нить NAS с 200 мгц процом все более уныло чем на PC, п https://www.opennet.ru/openforum/vsluhforumID3/63734.html#35 Thu, 11 Feb 2010 13:49:55 GMT &gt;А dom0 ядра выкинули почему?<br><br>Ну, как... Все были уверены, что _Debian медленно релизит, но оказалось, что lenny вышел _слишком быстро для "оставшихся" в районе 2.4.18(?) апстримов Xen-а и "не успевших" за не то что Торвальдс&ко, но даже за релизом Debian........................<br><br>http:/openforum/vsluhforumID15/2213.html#1<br><br>Уже-всё-ещё и к выходу squeeze-а "не поспевают". Во всём виноват Торвальдс?<br><br>&gt;теперь ручками собираем или теперь новые ядра сразу умеют dom0 из коробки (как domU) ? <br><br>http://wiki.debian.org/Xen, http://wiki.debian.org/DebianRussian/Xen<br> https://www.opennet.ru/openforum/vsluhforumID3/63734.html#34 Thu, 11 Feb 2010 13:24:10 GMT &gt;&gt; &lt;legion&gt; это бага в dash<br>&gt;Напугали тестера багами :)<br><br>То есть пользователи dash -- заведомо тестеры? Как страшно жить. :)<br><br>&gt;Вы хотите сказать что в bash багов нет?<br><br>Я хочу сказать, что не всякая регрессия при переходе с sh на dash -- обязательно неадекватность разработчика скрипта.<br><br>&gt;Ну и в dash вытопчут.<br><br>Надеюсь. :)<br><br>&gt;Зато если на чем-то с слабым процом (handhelds, embedded) поюзать баш - <br>&gt;сразу станет понятно насколько он монструозен и тормознут.<br><br>Будет под рукой альт -- посмотрите через прицел time и ldd на тамошний /bin/sh. Ну или сюда, по вкусу:<br>http://git.altlinux.org/people/ldv/packages/?p=bash.git;a=blob;f=bash.spec;h=5dbdb990f11860b5dfd507aeef8bd959661b33e5;hb=HEAD#l148<br><br>Сделано именно с целью ускорения запуска скриптов.<br><br>&gt;&gt;PS: Вы не пытались рефакторить и компрессировать свои постинги? <br>&gt;Боюсь форумный движок не оценит по достоинству вывод гзипа :P.<br><br>Существуют разные методы {с,от}жатия. :)<br><br>&gt;А насчет рефакторинга - это надо стиль мышления несколько перестроить. <br><br>Мне по