From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Wed, 26 Nov 2003 15:48:14 +0300 From: =?koi8-r?B?5MXOydMg883J0s7P1w==?= To: ALT Devel discussion list Subject: Re: [devel] =?koi8-r?B?z8Igz8LT1dbExc7J?= =?koi8-r?B?ySDQz8TIz8TP1yDLIM/Dxc7LxSDOwcSj1s7P09TJ?= Sisyphus Message-ID: <20031126124814.GA25325@localhost.localdomain> References: <20031125001230.D78905@elefant.dgtu.donetsk.ua> <20031125072830.GE2421@basalt.office.altlinux.org> <20031125094848.GH10424@osdn.org.ua> <20031125122911.GA9809@basalt.office.altlinux.org> <20031125225916.GE19276@localhost.localdomain> <20031126082752.GD24420@basalt.office.altlinux.org> <20031126111514.GA20469@localhost.localdomain> <20031126121542.GD9008@basalt.office.altlinux.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pWyiEgJYm5f9v55/" Content-Disposition: inline In-Reply-To: <20031126121542.GD9008@basalt.office.altlinux.org> X-BeenThere: devel@altlinux.ru X-Mailman-Version: 2.1.3 Precedence: list Reply-To: ALT Devel discussion list List-Id: ALT Devel discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2003 14:13:04 -0000 Archived-At: List-Archive: List-Post: --pWyiEgJYm5f9v55/ Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit On Wed, Nov 26, 2003 at 03:15:42PM +0300, Stanislav Ievlev wrote: >> Цель -- _увеличить надёжность_. То есть _уменьшить вероятность сбоя_, а не >> свести её к нулю (что, как я уже говорил, принципиально невозможно при >> нынешней практике писать софт на си). > ради любопытства: причём здесь си. Потому что самое большое количество ошибок безопасности, например, это переполнение буфера, которое невозможно в языках, где есть тип данных "строка" и нет адресной арифметики. Эти два факта (отсутствие строк и присутствие адресной арифметики) превращают этот язык в диверсию отраслевого масштаба. Си это язык для профессионала-системщика, так же как и C++. К сожалению сейчас использование других языков сопряжено с проблемами, которые всегда вылезают когда отходишь от средств используемых большинством. Кроме того на более других языках возможно делать доказательство по карйней мере отдельных частей программ, что на си фактически невозможно. Дальнейшие разговоры на эту тему предлагаю провести в talk-room, так как тема слишком провокативная. > Итак, мне понятна мысль - сделать два Сизифа с "запаздыванием по времени". > Но до сих пор не понятно почему для этого нельзя использовать связку > Сизиф-Дедал. По моему разумению результат от введения ещё одного Сизифа > сопоставим (при значительно меньших затратах) от более эффективного > использования Дедала. Дело в том, что в Дедал идут пакеты, которые изначально подразумевается что недостаточно готовы, чтобы отправиться конечному пользователю. В Сизиф идут пакеты, о которых мантейнер по крайней мере надеется, что пользователь может их использовать. > Ключевой момент в моей позиции - мы получим ещё один Дедал ибо люди (будь > то пользователи или разработчики) будут сознательно или несознательно > избегать использования пакетов, объявленных как нестабильные. Зачем нам > ещё одна прослойка которая будет использоваться на 30%. Я предлагаю создать не ещё одну тестовую прослойку, а наоборот, отслоить более надёжную версию Сизифа. > Если уж нужен какой "отстойник" пакетов - то для этих целей можно > использовать уже существующий incoming: он доступен на чтение всем > разработчикам, а забирать в Сизиф можно только пакеты которые отлежались > там например 3 дня. Результат будет одинаковый. Это преувеличение. > Много пакетов придётся проверять в скрипте: например может появиться > принципиально новый пакет который просто обсолетит другой пакет в Сизифе. Ну и что? Если мантейнер один и тот же, то как только принимается решение о том, что пакет может быть перемещён в Сизиф, то пакет из Сизифа удаляется. Кстати, как сейчас это решается технически? incominger делает это ручками? -- С уважением, Денис http://freesource.info --pWyiEgJYm5f9v55/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/xKEO9yLOUeHSdCYRAgkmAKCSHdJJdhy4t4l0kvwBUTHCI+RaIwCfRiZw CCd3NAwtwSOoZ2GWuAqcr8A= =ow0q -----END PGP SIGNATURE----- --pWyiEgJYm5f9v55/--