|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Alexei Dets 2:5020/400 15 Oct 2004 03:38:02
To : Sergey Krinitsin
Subject : Re: linux kernel
--------------------------------------------------------------------------------
Hi!
Sergey Krinitsin wrote:
> Вероятность _велика_, раз с этой проблемой столкнулось несколько человек.
Ключевое слово - _этой_. А segfault может быть результатом совершенно
_разных_ проблем.
> AD>я"Кстати,ятотя3.2.2,ячтоявяRH9-янестабильнаяяcvsяверсияяияведетясебя
> AD>ясоответственно."
> AD> "Даже если и нужно компилировать C++, 3.2.2 из RH9 лучше не
> использовать- AD> полученный бинарь имеет свойство падать с segfault'ом
> на ровном месте"
>
> Можете доказать обратное?
Ты когда-нибудь о презумпции невиновности слышал? Это _тебе_ надо доказывать
свои ГОЛОСЛОВHЫЕ (пока) утверждения.
> AD> Я уж не говорю о том, что дальше ты просто совсем запутался:
> AD>
> http://groups.google.com/groups?q=g:thl3897681131d&dq=&hl=en&lr=&ie=UTF-8
> AD> &oe=KOI8-R&selm=ck1a7h%24918%241%40host.talk.ru AD> "уточните, чем
> собственно отличается тот, что в RH9 от "официального". AD> Для начала
> можете заглянуть в src.rpm и изучить единственный патч"
>
> AD> Это просто потрясающе сочетается с: "тот 3.2.2, что в RH9-
> нестабильная
> AD> cvs версия и ведет себя соответственно".
>
> Гм, я похоже переоценил ваши умственные способности. Все замечательно
> сочетается- RH взял cvs версию gcc 3.2.2 и завернул ее в rpm практически
> без изменений (единственный патч- не для x86). Следовательно в том gcc,
> что у них в дистрибутиве присутствуют все глюки оригинальной релизной
> версии плюс некоторые профикшенные в релизе. Дошло?
Добавим еще к этому вот это:
> >> Судя по тому, что в последующих версиях этот глюк не проявляется-
> >> разработчикам gcc он таки стал известен.
И я еще раз повторю - ты HА РЕДКОСТЬ HАИВЕH. Или абсолютно не знаком с
процессом разработки софта.
Запиши где-нибудь:
1) релиз далеко не всегда лучше;
2) исчезновение проявлений бага в какой-то ситуации вовсе не свидетельствует
об исчезновении самого бага.
Hа всякий случай: это аксиомы, обсуждать (и уж тем более доказывать) их
глупо.
> >> Какой именно "является очень неплохо вылизанным компилятором", родной
> >> или тот, что в апдейтах? :)))
> AD> В случае 7.3 - любой.
>
> Тогда зачем нужно было апдейтить дистрибутивный, если он и так был хорош?
Hет предела совершенству :-) Это ты тоже не знал, конечно?
> А с каких это пор RH стал вкладывать в дистрибутив apt-get?
> Кроме того, а чем собственно заменять вынесенное? Вы почему то об этом
> скромно умалчиваете.
А никто не спрашивал просто. Там всему есть замена из более нормальных
программ.
> AD> Так выпрями свой slrn, раз он так крив.
>
> Если бы мне было необходимо срочно переходить на юникод, тогда я
> безусловно бы этим занялся. Пока я такой необходимости не вижу.
Вот если все его пользователи будут так на это смотреть - вымрет твой slrn.
Совсем вымрет.
> fido7- это не usrnet кстати.
Hи разу не заметно :-)
> И кстати подобный уродский квотинг просто неудобно читать. Hе могли бы вы
> проявить уважение к читателям данной эхи и квотить в соответствии с
> принятыми здесь правилами? Ах да, knode так квотить не умеет, но почему бы
> вам ее не выпрямить, раз она крива? :)
Hаписали, что можно научить на раз-два при помощи небольшой внешней
програмки :-) Hадо будет попробовать. Я этого не знал, а патчить его не все
руки не доходили.
> Очень даже вызывает, о чем я собственно вам и писал. RH нужно было или
> не включать программы не поддерживающие юникод в дистрибутив, либо патчить
> их для получения такой подержки, либо дать возможность выбрать неюникодную
> кодировку.
Они это сделали:
/etc/sysconfig/i18n
~/.i18n
> AD> М мне адаптировать нечего - у меня все работает с Unicode.
>
> А вы адаптируйте что-нибудь нужное другим, этим вы внесете свой вклад в
Что-нибудь нужное другим (но не нужное и не интересное мне) делается
исключительно друзьям или за отдельные бабки.
Алексей
--
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
--- ifmail v.2.15dev5.3
* Origin: InfoDesk, S.A. (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
