Re: AMD64 vs. Intel x86
Michael Shigorin пишет: On Wed, Dec 12, 2007 at 01:46:37AM +0300, ph wrote: Для меня например важна возможность поднимать amd64 и i386 vservers на одной машине. Удобно. Ой, а ты до сих пор на vserver? 8-) А чем плох vserver? По крайней мере 1.x представлял из себя классический набор костылей и подпорок в лучшем админском стиле; в 2.x некоторые более осмысленные идеи появились, но недавнее интервью с основным разработчиком убедило в правильности решения сваливать с vs. А можно поподробнее? Собственно, решение было принято на основании совета Димы Левина, который, в свою очередь, аргументировал его результатами своего осмотра vserver и очень положительным отзывом о результатах аудита одним из известных российских экспертов в области безопасности кода openvz. и тут тоже - гуголь дал только ссылки на конф в Протве, но там касательно ovz\vserver практически ничего нет. Разумеется, у ovz есть свои заморочки (очень долго починяли NFS, например) -- но одно управление ресурсами для нас того стоит. На ovz получается иметь в одном, причём далеко не сверхмощном, тазу одновременно рабочий терминальный сервер, три сборочницы и ещё несколько служебных или девелоперских контейнеров. После разводки этого всего по полудесятку шпинделей (IDE/SATA/SCSI) :-) Полудесяток, без базара, гораздо круче просто пяти :-) никто никому жить не мешает даже при затыкающем отдельно взятую систему I/O во время формирования сборочных чрутов hasher'ами... и двухуровневый скедулер тут не последнюю роль играет. -- С уважением, Любимец Андрей Алексеевич -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: вопрос по http://bugs.debian.org/release-critical/
Stanislav Maslovski wrote: On Thu, Dec 13, 2007 at 09:47:37PM +0200, Oleg Gashev wrote: Приветствую, Stanislav Maslovski wrote: И как же Вы пользуясь своей гипотезой объясните линейный рост числа багов в промежутке между 01.07.2007 и текущим датой на 400 единиц? Очевидно, что не в старых багах дело. Покажите мне софт, в котором нету багов. P.S. То, что есть баги, это очень хорошо. Они должны быть. Плохо, когда их нет. Все верно, и это только подтверждает мой исходный тезис. Стабильный в случае дебиана значит в первую очередь не меняющийся, а вовсе не лишённый багов. Софта без багов не бывает. С этим ничего не сделаешь. А тогда (по крайней мере в некоторых контекстах) заметно проще, если баги остаются те же, и соответственно и способы их обхода тоже те же. Если используемый на сервере дистрибутив менять, скажем, раз в несколько месяцев (или, не дай бог, всякий раз когда testing обновляется) - то ровно с такой же периодичностью придётся встречать новый комплект багов и как-то решать проблемы, из-за этих багов возникающие. Вместо того, чтобы заниматься делом. Большое спасибо политике debian, из-за которой мне приходится этим заниматься реже. P.S. Использую сервера и десктопы на etch. Полёт нормальный. P.P.S. Почему-то так вышло, что использовать десктопы на testing/unstable я прекратил примерно тогда же, когда стало по-настоящему много работы. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: вопрос п о http://bugs.debian.org/release-critical/
On Fri, Dec 14, 2007 at 03:08:18PM +0300, Nikita V. Youshchenko wrote: Stanislav Maslovski wrote: On Thu, Dec 13, 2007 at 09:47:37PM +0200, Oleg Gashev wrote: Приветствую, Stanislav Maslovski wrote: И как же Вы пользуясь своей гипотезой объясните линейный рост числа багов в промежутке между 01.07.2007 и текущим датой на 400 единиц? Очевидно, что не в старых багах дело. Покажите мне софт, в котором нету багов. P.S. То, что есть баги, это очень хорошо. Они должны быть. Плохо, когда их нет. Все верно, и это только подтверждает мой исходный тезис. Стабильный в случае дебиана значит в первую очередь не меняющийся, а вовсе не лишённый багов. Дело как раз в том, что многие этого не понимают, и продолжают утверждать обратное. В частности, это хорошо видно в этой рассылке, например, когда речь заходит о версии ядра. Софта без багов не бывает. С этим ничего не сделаешь. А тогда (по крайней мере в некоторых контекстах) заметно проще, если баги остаются те же, и соответственно и способы их обхода тоже те же. Если используемый на сервере дистрибутив менять, скажем, раз в несколько месяцев (или, не дай бог, всякий раз когда testing обновляется) - то ровно с такой же периодичностью придётся встречать новый комплект багов и как-то решать проблемы, из-за этих багов возникающие. Вместо того, чтобы заниматься делом. Большое спасибо политике debian, из-за которой мне приходится этим заниматься реже. Потому и нужно произвести деление дистрибутива на (грубо говоря) системный софт + библиотеки и десктопный софт + тулкиты и отказаться от глобального фриза. Получился бы и не вариант убунты, где нестабильно всё подряд, и не текущий вариант, где stable == static. Из обсуждаемых графиков видно, что скорость отлова RC багов после релиза Etch оказалась заметно выше, чем это происходило в течение фриза. Вероятно, это связано просто с тем, user base у стабильной ветки обширнее, чем у тестинга/или нестабильной. На мой взгляд, это ставит под вопрос эффективность глобального фриза, как средства борьбы с багами. -- Stanislav
Re: вопрос по htt p://bugs.debian.org/release-critical/
Stanislav Maslovski - debian-russian@lists.debian.org @ Fri, 14 Dec 2007 16:28:43 +0300: SM Из обсуждаемых графиков видно, что скорость отлова RC багов после релиза SM Etch оказалась заметно выше, чем это происходило в течение фриза. Вероятно, SM это связано просто с тем, user base у стабильной ветки обширнее, чем у SM тестинга/или нестабильной. На мой взгляд, это ставит под вопрос SM эффективность глобального фриза, как средства борьбы с багами. Выкидываем фриз и что получаем? Debian хорош именно статичностью. Т.е. тем что он работает из-зо дня в день и так как мне надо. И если мне нужен, допустим, новая версия пакета А то я просто ставлю его из backports. Очень удобно. -- .''`. Kirill A. Korinskiy [EMAIL PROTECTED] : :' : proud (maniac)? (developer|hacker) `. `'` http://catap.ru/ - +7 (916) 3-604-704 - xmpp:[EMAIL PROTECTED] `- Debian - when you have better things to do than fixing systems -- madduck pgp2dvjm9Z1WJ.pgp Description: PGP signature
часы на 945 чип сете
что-то никак не выходит у меня заставить работать часы на 945 чипсете hwclock --show, например с такой ошибкой обламывается: select() to /dev/rtc to wait for clock tick timed out в логе такие записи при попытках ntpd воздействовать на время: Dec 14 16:45:11 obuhov kernel: rtc_cmos: probe of 00:03 failed with error -16 ну и так далее. все что с временем связано не работает. два хоста с 945-м и на обоих одинаково на других чипсетах нормально все. 2.6.22 ставил думал там драйвера поновее - разницы никакой. есть варианты как настроить время на этих материнских платах? -- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: часы на 945 чипсете
В Птн, 14/12/2007 в 16:49 +0300, Dmitry E. Oboukhov пишет: что-то никак не выходит у меня заставить работать часы на 945 чипсете hwclock --show, например с такой ошибкой обламывается: select() to /dev/rtc to wait for clock tick timed out в логе такие записи при попытках ntpd воздействовать на время: Dec 14 16:45:11 obuhov kernel: rtc_cmos: probe of 00:03 failed with error -16 ну и так далее. все что с временем связано не работает. два хоста с 945-м и на обоих одинаково на других чипсетах нормально все. 2.6.22 ставил думал там драйвера поновее - разницы никакой. есть варианты как настроить время на этих материнских платах? Я сделал так: в /etc/modprobe.d/blacklist добавил: blacklist rtc и всё заработало. Система Etch. -- Покотиленко Костик [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: часы на 945 чипсете
Dmitry E. Oboukhov - debian-russian@lists.debian.org @ Fri, 14 Dec 2007 16:49:22 +0300: DEO есть варианты как настроить время на этих материнских платах? Можно попробовать вписать в /etc/default/rcS: HWCLOCKPARS=--directisa Для моего ноута помогло, хотя какой чипсет там я не помню :) Помойму 945 -- .''`. Kirill A. Korinskiy [EMAIL PROTECTED] : :' : proud (maniac)? (developer|hacker) `. `'` http://catap.ru/ - +7 (916) 3-604-704 - xmpp:[EMAIL PROTECTED] `- Debian - when you have better things to do than fixing systems -- madduck pgpwrlZZg6aSx.pgp Description: PGP signature
Re: вопрос по http://bugs.debian.org/release-critical/
14.12.07, Stanislav Maslovski[EMAIL PROTECTED] написал(а): Потому и нужно произвести деление дистрибутива на (грубо говоря) системный софт + библиотеки и десктопный софт + тулкиты и отказаться от глобального фриза. Получился бы и не вариант убунты, где нестабильно всё подряд, и не текущий вариант, где stable == static. Что это даст? Какую проблему решит? -- Regards, Yuri Kozlov
Re: [OFFTOP] привязка клавиш в fvwm
Yuri Kozlov - debian-russian@lists.debian.org @ Thu, 13 Dec 2007 20:36:54
+0300:
YK Потихоньку читаю man сего чудного менеджера. Вопрос: хочу повесить
YK команду на комбинацию клавиш Shift_L F9. Именно на левый, а не на
YK любой из. Как?
Если я правильно ошибаюсь, для этого сначала надо добиться от иксов,
чтобы они показывали приложению левый шифт не таким модификатором, как
правый. Будет больно. Очень.
YK Посмотрел xkeycaps. Наживаешь левый шифрт -- левый шифт
YK жёлтеньким закрашивается, а правый нет.
YK То есть для xkeycaps ничего не надо, оно и так умеет?
YK В чём разница программы от fvwm?
Она, так же как xev, смотрит не на нормальный интерфейс, а на
беспощадный. Нижнего уровня.
--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]
Человек - терновый венец природы.
Кнышев
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [OFFTOP] привязка клавиш в fvwm
Yuri Kozlov - debian-russian@lists.debian.org @ Fri, 14 Dec 2007 18:32:49
+0300:
YK Потихоньку читаю man сего чудного менеджера. Вопрос: хочу повесить
YK команду на комбинацию клавиш Shift_L F9. Именно на левый, а не на
YK любой из. Как?
Если я правильно ошибаюсь, для этого сначала надо добиться от иксов,
чтобы они показывали приложению левый шифт не таким модификатором, как
правый. Будет больно. Очень.
YK Посмотрел xkeycaps. Наживаешь левый шифрт -- левый шифт
YK жёлтеньким закрашивается, а правый нет.
YK То есть для xkeycaps ничего не надо, оно и так умеет?
YK В чём разница программы от fvwm?
Она, так же как xev, смотрит не на нормальный интерфейс, а на
беспощадный. Нижнего уровня.
YK Наверно. Неужели ниже Х-ов? Но при этом вроде никому не мешает.
YK Это я к тому, что можно же выковырять клавиши, ничего не поломав и
YK не настраивая.
Нет, не ниже. Просто на таком уровне, на котором нормальные программы
не работают.
YK Жалко fvwm этого не умеет. Может модуль какой есть? :)
Можно сделать, я думаю. Но ... почитай в man fvwm описание
IgnoreModifiers, включая Important Note. Оно, насколько я могу
понять, работает примерно по той же схеме, что xev.
Поосторожнее с этим.
--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]
Не сломалось - не чини.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [OFFTOP] привязка клавиш в fvwm
14.12.07, Artem Chuprina[EMAIL PROTECTED] написал(а): Yuri Kozlov - debian-russian@lists.debian.org @ Thu, 13 Dec 2007 20:36:54 +0300: YK Потихоньку читаю man сего чудного менеджера. Вопрос: хочу повесить YK команду на комбинацию клавиш Shift_L F9. Именно на левый, а не на YK любой из. Как? Если я правильно ошибаюсь, для этого сначала надо добиться от иксов, чтобы они показывали приложению левый шифт не таким модификатором, как правый. Будет больно. Очень. YK Посмотрел xkeycaps. Наживаешь левый шифрт -- левый шифт YK жёлтеньким закрашивается, а правый нет. YK То есть для xkeycaps ничего не надо, оно и так умеет? YK В чём разница программы от fvwm? Она, так же как xev, смотрит не на нормальный интерфейс, а на беспощадный. Нижнего уровня. Наверно. Неужели ниже Х-ов? Но при этом вроде никому не мешает. Это я к тому, что можно же выковырять клавиши, ничего не поломав и не настраивая. Жалко fvwm этого не умеет. Может модуль какой есть? :) -- Regards, Yuri Kozlov
Re: часы на 945 чипсете
Из форума на www.lafox.net В общем-то решение проблемки оказалось в следующем. Все эти UTC и прочее оно конечно в общем-то вроде как и причем, но я еще при установке все ввел правильно, так что проблема оказалась несколько глубже, а сегодня как раз в связи с отсутствием доступа в свои продуктивные системы у пана був час та натхнення поразбираться. И так, в общем при загрузке в логах была обнаружена следующая строка: Код Unable to time select() to /dev/rtc to wait for clock tick timed out Ага сказал я себе, таки наверное ж...а именно в этом rtc, так как это вообще-то что-то типа real time clock судя из буквочек и наверное система то, до часиков биоса достучаться не может. В общем решение проблемы следующее: Для Debian 4.0 (etch) Пойти по пути /etc/default/rcS и там добавить в файлик строчку Код HWCLOCKPARS=--directisa Затем найти файлик типа /sbin/hwclock и переименовать его в /sbin/hwclock.dist или как хочется по другому. После этого сделать скрипт который назвать /sbin/hwclock Код #!/bin/sh /sbin/hwclock.dist --directisa $@ Дать ему все права на выполнение, по аналогии с правами на переименованный /sbin/hwclock.dist, ну и все, после этого ошибки больше нет, так как прямой доступ к таймеру биоса обеспечили. Такое вот счастье. В общем кому подробнее, проблема описана тут http://www.thinkwiki.org/wiki/Problems_wit..._4.0_.28etch.29 такая фигня может проявляться на разных системах. Метод решения или пересборка ядра как я понял с включением альтернативного RTC драйвера или выше описанный метод. On Птн, 2007-12-14 at 16:49 +0300, Dmitry E. Oboukhov wrote: что-то никак не выходит у меня заставить работать часы на 945 чипсете hwclock --show, например с такой ошибкой обламывается: select() to /dev/rtc to wait for clock tick timed out в логе такие записи при попытках ntpd воздействовать на время: Dec 14 16:45:11 obuhov kernel: rtc_cmos: probe of 00:03 failed with error -16 ну и так далее. все что с временем связано не работает. два хоста с 945-м и на обоих одинаково на других чипсетах нормально все. 2.6.22 ставил думал там драйвера поновее - разницы никакой. есть варианты как настроить время на этих материнских платах? -- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537 -- With best regards Tochenyk Oleg E-mail: [EMAIL PROTECTED] PS: Не думай, что ты умнее начальника. Будешь думать - не станешь начальником. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: AMD64 vs. Intel x86
Andrey Lyubimets - debian-russian@lists.debian.org @ Fri, 14 Dec 2007
14:04:59 +0600:
и ещё несколько служебных или девелоперских контейнеров. После
разводки этого всего по полудесятку шпинделей (IDE/SATA/SCSI)
AL :-) Полудесяток, без базара, гораздо круче просто пяти :-)
Полудесяток - это от 4 до 7, особенно если хозяин уже не помнит точно,
сколько.
--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]
mv /dev/rookie /dev/hands
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [OFFTOP] привязка клавиш в fvwm
On Friday 14 December 2007 18:58, Artem Chuprina wrote: Yuri Kozlov - debian-russian@lists.debian.org @ Fri, 14 Dec 2007 18:32:49 +0300: YK Наверно. Неужели ниже Х-ов? Но при этом вроде никому не мешает. YK Это я к тому, что можно же выковырять клавиши, ничего не поломав и YK не настраивая. Нет, не ниже. Просто на таком уровне, на котором нормальные программы не работают. Не удержусь... Там нужны Инные программы, которые умеют выходить в сумрак, хотя бы на первый уровень :)) -- Макс Дмитриченко -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: часы на 945 чипсете
On Friday 14 December 2007 16:49, Dmitry E. Oboukhov wrote: что-то никак не выходит у меня заставить работать часы на 945 чипсете hwclock --show, например с такой ошибкой обламывается: select() to /dev/rtc to wait for clock tick timed out в логе такие записи при попытках ntpd воздействовать на время: Dec 14 16:45:11 obuhov kernel: rtc_cmos: probe of 00:03 failed with error -16 ну и так далее. все что с временем связано не работает. два хоста с 945-м и на обоих одинаково Говорят, что это общая бага для двуядерных камней. От чипсета не зависит. У меня такое же на i965. Дома правда стоит iP35, там вроде бы нет. Наверное, ещё от биоса зависит. Как пить дать кто-то в какой-нить таблице ACPI опять налажал. Как правильно заметили --direct-isa спасает отца русской демократии. -- Макс Дмитриченко -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: вопрос по http://bugs.debian.org/release-critical/
Из обсуждаемых графиков видно, что скорость отлова RC багов после релиза Etch оказалась заметно выше, чем это происходило в течение фриза. Huh? Etch был выпущен 8 апреля. Непосредственно после этого момента графики РЕЗКО идут вверх. То есть, etch был выпущен без известных на тот момент RC багов (плюс-минус некоторые детали). После этого было обнаружено некоторое количество новых багов - это естественный процесс. В случае выпуска релиза без freeze, в релизе уже на момент его выпуска было N серьёзных багов. А новые баги, обнаруженные с этого момента, к этим N бы добавлялись. То есть ситуация была бы хуже ровно настолько, сколько в среднем открыто багов на момент, когда нет фриза. Потому и нужно произвести деление дистрибутива на (грубо говоря) системный софт + библиотеки и десктопный софт + тулкиты и отказаться от глобального фриза. Получился бы и не вариант убунты, где нестабильно всё подряд, и не текущий вариант, где stable == static. Стабильность (в смысле неизменчивость) разным людям нужна в разных частях дистрибутива. Деление, удовлетворяющее всех, невозможно. Текущая ситуация (stable + минимум backports) кажется правильнее. Каждый может поставить именно ту свежатинку, которая именно ему нужна. А нужна она не так уж и часто (я имею в виду нужна для конкретной цели, а не ддля удовлетворения жажды новых версий). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [OFFTOP] привязка клавиш в fvwm
Max Dmitrichenko - debian-russian@lists.debian.org @ Fri, 14 Dec 2007
19:06:07 +0300:
YK Наверно. Неужели ниже Х-ов? Но при этом вроде никому не мешает.
YK Это я к тому, что можно же выковырять клавиши, ничего не поломав и
YK не настраивая.
Нет, не ниже. Просто на таком уровне, на котором нормальные программы
не работают.
MD Не удержусь...
MD Там нужны Инные программы, которые умеют выходить в сумрак, хотя бы
MD на первый уровень :))
По-моему, по данной теме следует читать Иные книги...
--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]
An ideal world is left as an exercise to the reader.
Paul Graham, On Lisp
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Проблема с удалением файла
Собственно проблема с самособранным файлом, при удалении выскакивает такое вот: Reading package lists... Building dependency tree... The following packages will be REMOVED nvr-cr 0 upgraded, 0 newly installed, 1 to remove and 66 not upgraded. Need to get 0B of archives. After unpacking 21.5MB disk space will be freed. Do you want to continue [Y/n]? (Reading database ... dpkg: error processing nvr-cr (--remove): files list file for package `nvr-cr' contains empty filename Errors were encountered while processing: nvr-cr Processing was halted because there were too many errors. E: Sub-process /usr/bin/dpkg returned an error code (1) Уважаемые, подскажите плз куда копать, или может кто уже сталкивался?
Re: Проблема с удалением файла
chaos - debian-russian@lists.debian.org @ Fri, 14 Dec 2007 21:19:28 +0200:
c Собственно проблема с самособранным файлом, при удалении выскакивает такое
c вот:
c Reading package lists...
c Building dependency tree...
c The following packages will be REMOVED
c nvr-cr
c 0 upgraded, 0 newly installed, 1 to remove and 66 not upgraded.
c Need to get 0B of archives.
c After unpacking 21.5MB disk space will be freed.
c Do you want to continue [Y/n]? (Reading database ... dpkg: error processing
c nvr-cr (--remove):
c files list file for package `nvr-cr' contains empty filename
c Errors were encountered while processing:
c nvr-cr
c Processing was halted because there were too many errors.
c E: Sub-process /usr/bin/dpkg returned an error code (1)
c Уважаемые, подскажите плз куда копать, или может кто уже сталкивался?
Ну вон же оно подсказало: пустое имя файла в списке файлов. Залезь
руками в список файлов (/var/lib/dpkg/info/, дальше сам найдешь) и удали
его оттуда. Ну и стоит разобраться, откуда оно там взялось. Это может
зависеть от того, как делался пакет.
--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]
Пришел в гости математик, почитать новую рукопись. Вычитал из нее трех
героев напрочь, и ушел.
Gimli on #arda
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: вопрос п о http://bugs.debian.org/release-critical/
On Fri, Dec 14, 2007 at 06:18:54PM +0300, Nikita V. Youshchenko wrote: Из обсуждаемых графиков видно, что скорость отлова RC багов после релиза Etch оказалась заметно выше, чем это происходило в течение фриза. Huh? Etch был выпущен 8 апреля. Непосредственно после этого момента графики РЕЗКО идут вверх. Вероятно, Вы про зеленую кривую. С ней все ясно и вопросов нет. Синяя же кривая, которая показывает RC баги в stable, прыгает вверх в районе июня 2007-го года. Я полагаю, что этот скачок надо рассматривать просто как начальную точку отсчета, ведь раньше подобной статистики не велось. На всякий случай поясню, что под скоростью отлова я подразумевал скорость выявления багов т.е. частоту подачи багрепортов, а не скорость их исправления. Может быть это вызвало Ваше Huh? То есть, etch был выпущен без известных на тот момент RC багов (плюс-минус некоторые детали). Я в курсе. После этого было обнаружено некоторое количество новых багов - это естественный процесс. Некоторое? 600 - 200 = 400 за примерно полгода, синяя кривая. И это RC баги на версии пакетов в stable. Ведь не случайно же я поднял эту тему. Давайте разберемся, что это за баги. В случае выпуска релиза без freeze, в релизе уже на момент его выпуска было N серьёзных багов. А новые баги, обнаруженные с этого момента, к этим N бы добавлялись. То есть ситуация была бы хуже ровно настолько, сколько в среднем открыто багов на момент, когда нет фриза. Нет. С физической точки зрения, репорты и исправление багов - динамический процесс. На мой взгляд, длительный фриз искусственно создает ситуацию, когда скорость репортинга становится меньше скорости фиксинга, в результате чего, по прошествии полутора-двух лет, кривая-таки доходит до нуля и наступает момент релиза. Каково же при этом количество скрытых, неисправленных багов - на это нельзя дать простого ответа. Почему мне и хочется, собственно, понять, что иллюстрирует собой эта быстро растущая синяя кривая: что-то искусственное или то, о чем я пишу выше. Потому и нужно произвести деление дистрибутива на (грубо говоря) системный софт + библиотеки и десктопный софт + тулкиты и отказаться от глобального фриза. Получился бы и не вариант убунты, где нестабильно всё подряд, и не текущий вариант, где stable == static. Стабильность (в смысле неизменчивость) разным людям нужна в разных частях дистрибутива. Деление, удовлетворяющее всех, невозможно. Текущая ситуация (stable + минимум backports) кажется правильнее. Каждый может поставить именно ту свежатинку, которая именно ему нужна. А нужна она не так уж и часто (я имею в виду нужна для конкретной цели, а не ддля удовлетворения жажды новых версий). К сожалению даже при этом число пакетов, которые я сам собираю/бакпорчу быстро разрастается до того, что уследить за ними становится сложно. -- Stanislav
Re: часы на 945 чипсете
Max Dmitrichenko wrote: On Friday 14 December 2007 16:49, Dmitry E. Oboukhov wrote: что-то никак не выходит у меня заставить работать часы на 945 чипсете hwclock --show, например с такой ошибкой обламывается: select() to /dev/rtc to wait for clock tick timed out в логе такие записи при попытках ntpd воздействовать на время: Dec 14 16:45:11 obuhov kernel: rtc_cmos: probe of 00:03 failed with error -16 ну и так далее. все что с временем связано не работает. два хоста с 945-м и на обоих одинаково Говорят, что это общая бага для двуядерных камней. От чипсета не зависит. У меня такое же на i965. Дома правда стоит iP35, там вроде бы нет. Наверное, ещё от биоса зависит. Как пить дать кто-то в какой-нить таблице ACPI опять налажал. Как правильно заметили --direct-isa спасает отца русской демократии. Интересный факт, жил до этого на самособранном ядре 2.6.23.9 - всё было хорошо и часы работали как часы :) по некоторой необходимости поставил дистрибутивное ядро - сразу же сбились часы. помогли удаление модуля rtc или обращение к hwclock с ключем --directisa странно всё это .. -- Bye TimHisTeam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: вопрос п о http://bugs.debian.org/release-critical/
On Fri, Dec 14, 2007 at 06:27:45PM +0300, Yuri Kozlov wrote: 14.12.07, Stanislav Maslovski[EMAIL PROTECTED] написал(а): Потому и нужно произвести деление дистрибутива на (грубо говоря) системный софт + библиотеки и десктопный софт + тулкиты и отказаться от глобального фриза. Получился бы и не вариант убунты, где нестабильно всё подряд, и не текущий вариант, где stable == static. Что это даст? Какую проблему решит? Это удовлетворит как сисадминов, которым достаточно базовой системы с набором сервисов, так и пользователей прикладного софта, который фиксится, как правило, быстрее в апстриме, чем усилиями сопровождающего. Кстати, по поводу того, как делить. Надо подойти к задаче статистически и связать в одну модель такие параметры, как: 1) важность пакета (например, оценить можно по числу зависящих от него, рекурсивно, с весом, пропорциональным их собственной важности) 2) частота выхода новых версий 3) частота багрепортов 4) частота исправлений Далее, сформировать некий критерий и по его значению поделить. Периодически пересчитывать критерий и корректировать списки пакетов. -- Stanislav
часы на 945 чип сете
Интересный факт, жил до этого на самособранном ядре 2.6.23.9 - всё было хорошо и часы работали как часы :) по некоторой необходимости поставил дистрибутивное ядро - сразу же сбились часы. помогли удаление модуля rtc или обращение к hwclock с ключем --directisa странно всё это .. что же странного? значит в 2.6.23.9 модуль rtc работает со всеми чипсетами, а в более старых еще нет. это не странно а напротив - логично. вот если бы более старое ядро работало а более новое нет тогда бы было странно :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: вопрос по http://bugs.debian.org/release-critical/
Stanislav Maslovski - debian-russian@lists.debian.org @ Fri, 14 Dec 2007
23:12:31 +0300:
Потому и нужно произвести деление дистрибутива на (грубо говоря)
системный софт + библиотеки и десктопный софт + тулкиты и отказаться
от глобального фриза. Получился бы и не вариант убунты, где нестабильно
всё подряд, и не текущий вариант, где stable == static.
Что это даст? Какую проблему решит?
SM Это удовлетворит как сисадминов, которым достаточно базовой системы
SM с набором сервисов, так и пользователей прикладного софта, который
SM фиксится, как правило, быстрее в апстриме, чем усилиями
SM сопровождающего.
Ну, вообще-то такое деление уже есть. Есть stable, который можно
апгрейдить без страха, и есть testing, который достаточно свеж и может
ставиться на некритичные к если что машины.
Делить же основной дистрибутив на системный и десктопный смысла не
видно, ибо десктопные приблуды и десктопное железо все чаще норовят
захотеть ядро посвежее и соответствующие околоядерные софты. Каковые
ядро и софты - самые что ни на есть системные, системнее не бывает.
--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]
Вам правду резать или кусочком?
Кнышев
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: вопрос по http://bugs.debian.org/release-critical/
14.12.07, Stanislav Maslovski[EMAIL PROTECTED] написал(а): On Fri, Dec 14, 2007 at 06:27:45PM +0300, Yuri Kozlov wrote: 14.12.07, Stanislav Maslovski[EMAIL PROTECTED] написал(а): Потому и нужно произвести деление дистрибутива на (грубо говоря) системный софт + библиотеки и десктопный софт + тулкиты и отказаться от глобального фриза. Получился бы и не вариант убунты, где нестабильно всё подряд, и не текущий вариант, где stable == static. Что это даст? Какую проблему решит? Это удовлетворит как сисадминов, которым достаточно базовой системы с набором сервисов, так и пользователей прикладного софта, который фиксится, как правило, быстрее в апстриме, чем усилиями сопровождающего. Как я понял, вы предлагаете оставить stable только для базовых пакетов. Но это уже есть? Получается, проблем с этим у сисадминов нет. Если кого-то не устраивает скорость фиксации проблем с безопасностью в stable то, наверное, стоит перейти на платный дистрибутив. Остаются неопытные пользователи. Если по каким-то причинам не устраивает стабильная ветка -- всегда есть Ubuntu, которая решает вопросы с новым софтом. И релиз раз в полгода. Чего ещё нужно? Кстати, по поводу того, как делить. Надо подойти к задаче статистически и связать в одну модель такие параметры, как: 1) важность пакета (например, оценить можно по числу зависящих от него, рекурсивно, с весом, пропорциональным их собственной важности) 2) частота выхода новых версий 3) частота багрепортов 4) частота исправлений Далее, сформировать некий критерий и по его значению поделить. Периодически пересчитывать критерий и корректировать списки пакетов. Ага, и менять по каждому чиху список стабильных пакетов. Какая же стабильность получится? Может какая проблема с фризом и есть. Точнее с исправлением RC ошибок. Но менять из-за этого то, за что, фактически, и любят Debian, мне кажется не стоит. -- Regards, Yuri Kozlov
