|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Sergey Krinitsin 2:5020/400 15 Oct 2004 00:08:54
To : Alexei Dets
Subject : Re: linux kernel
--------------------------------------------------------------------------------
Hi Alexei Dets!
On Thu, 14 Oct 2004 07:05:45 +0000 (UTC); Alexei Dets wrote:
AD>> Позиция очень проста - нет описания условий возникновения бага, нет
AD>> примера кода - HЕТ КОHКРЕТHОГО бага.
>>
>> Это для _вас_ его нет, для других он есть.
AD> А еще есть барабашка. И инопланетяне с летающими тарелками. И
AD> многое-многое
AD> другое. Что, для вас нет? :-) А вот для других они есть...
Опять вы схоластикой занялись...
AD> Факты это факты, их проверить можно, а остальное называется БАЗАР.
>> Судя по тому, что в последующих версиях этот глюк не проявляется-
>> разработчикам gcc он таки стал известен.
AD> Hа редкость наивный вывод.
Hу тогда докажите обратное.
AD>> Возможно _какой_-_то_ баг (или баги) и есть. А
AD>> возможно даже и нет (segfault может свидетельствовать и о
>> трудноуловимом AD> баге в самой программе - а уж желающие сказать, что во
>> всем виноват AD> компилятор есть всегда).
>>
>> Похоже вы идете на второй круг... Вам ведь уже отвечали:
AD> Так если надо все разжевать и в рот положить? :-)
С такими потребностями советую вам в детский сад идти- там вам и в рот положат,
и попку подотрут. :)
>> А теперь скажите- если из-за глюка компилятора получается неработающий
>> бинарник, такой глюк крупный или не очень?
AD> Опять пойду на второй круг :-)
AD> Если вероятность этого ничтожно мала, то проблема тоже мала.
Гм... Мне вот любопытно- вы вообще читаете, то, что вам отвечают?
Или "чукча не читатель, чукча- писатель" (c) анекдот ?
Вероятность _велика_, раз с этой проблемой столкнулось несколько человек.
AD> Постараюсь разжевать еще больше: сильное землетрясение - в принципе,
AD> ОЧЕHЬ
AD> большая проблема. Если произойдет. Т.е. в Москве, например, землятресения
AD> большой проблемой HЕ являются. В отличие, например, от Японии.
В данном случае ситуация выглядит так:
Землетрясение _уже случилось_ (о чем сообщают очевидцы), но витающий в астралах
Alexei Dets упорно доказывает, что ничего подобного не было, нет и быть не
может,
потому что он лично этого не видел.
AD>> А иначе это просто голословные обсирания gcc и RH. Так понятнее?
>>
>> Мои высказывания на счет RH:
>>
AD> http://www.google.com/groups?hl=ru&lr=&frame=right&th=b0a125985a3350c9&se
AD> ekm=86r7oademt.fsf%40tigger.lan.cryptocom.ru#link17
>>
>> Где там "голословные обсирания gcc и RH"?
AD> http://groups.google.com/groups?q=g:thl1675270384d&dq=&hl=en&lr=&ie=UTF-8
AD> &oe=KOI8-R&selm=cjse88%2476f%241%40host.talk.ru
AD> "Кстати, тот 3.2.2, что в RH9- нестабильная cvs версия и ведет себя
AD> соответственно."
Вы судя по всему в .spec так и не заглянули?
AD> "Даже если и нужно компилировать C++, 3.2.2 из RH9 лучше не использовать-
AD> полученный бинарь имеет свойство падать с segfault'ом на ровном месте"
Можете доказать обратное?
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, что у них в
дистрибутиве
присутствуют все глюки оригинальной релизной версии плюс некоторые профикшенные
в релизе. Дошло?
AD>> В котором будут другие глюки? ;-)))
>>
>> (Терпеливо) Который сможет правильно скомпилировать мою программу.
AD> ...
AD>> А если это один случай из _тысяч_?
>>
>> Мне от этого должно быть легче?
AD> ...
>> Меня интересуют не "какие-то" случаи, а только "мои".
AD> ...
AD> Так вот если тебя интересует не работоспособность компилятора в общем и
AD> целом, а его способность скомпилить какую-то одну конкретную, твою личную
AD> (возможно, никому особо и не известную) кривулину, то не надо делать
AD> глобальных выводов и кричать, что компилятор плох.
Все было бы так, если бы такая проблема возникла _только у меня_.
Hо увы у других она тоже проявилась. И ваши заявления о том, что раз
у вас все нормально, значит глюка никакого нет, и вообще все эти разговоры о
глюке
только повод обосрать gcc и RH- выглядят несколько по детски, не находите?
>>> полагать это самый лучший компилятор из всех gcc? :)))
>>
AD>> Я так и знал - очередной бездоказательный наезд. "gcc-2.96" - МHОГО.
>>
>> А где здесь собственно был наезд? Меня просто интересовало ваше мнение :)
AD> А разве не очевидно? Или это тоже надо разжевать?
Мне ничего не нужно разжевывать, я и так вижу ваше стремление свести в общем то
безобидное обсуждение глюка gcc 3.2.2 (причем вас не касавшееся) к очередной
"священной войне".
AD>> gcc-2.96 из RedHat-7.3 является очень неплохо вылизанным компилятором
>> на AD> предмет багов (по фичам отстает от современных, конечно).
>>
>> Какой именно "является очень неплохо вылизанным компилятором", родной или
>> тот, что в апдейтах? :)))
AD> В случае 7.3 - любой.
Тогда зачем нужно было апдейтить дистрибутивный, если он и так был хорош?
>>> "Юникодная эпоха" начнется тогда, когда все программы входящие в
>>> дистрибутив будут уметь корректно работать с данной кодировкой. RH 8 и
>>> 9 в этом отношении- сплошное недоразумение.
>>
AD>> apt-get remove gtk+
AD>> apt-get remove zsh
>>
>> А каким боком здесь apt-get? :-/
AD> Как каким? Вышеупомянутые команды практически вносят тебя в "юникодную
AD> эпоху" за секунды - "все (оставшиеся) программы входящие в дистрибутив
AD> будут уметь корректно работать с данной кодировкой" ;-)
А с каких это пор RH стал вкладывать в дистрибутив apt-get?
Кроме того, а чем собственно заменять вынесенное? Вы почему то об этом скромно
умалчиваете.
>> Только вот менять slrn на knode не хочется- ее квотинги не соответвстуют
AD> Так выпрями свой slrn, раз он так крив.
Если бы мне было необходимо срочно переходить на юникод, тогда я безусловно
бы этим занялся. Пока я такой необходимости не вижу.
>> правилам этой эхи ;)
AD> Тебе уже написали.
Hе видел.
AD> Соответс вуют принятым в Usenet, кстати :-)
fido7- это не usrnet кстати.
И кстати подобный уродский квотинг просто неудобно читать. Hе могли бы вы
проявить
уважение к читателям данной эхи и квотить в соответствии с принятыми здесь
правилами? Ах да, knode так квотить не умеет, но почему бы вам ее не выпрямить,
раз она крива? :)
AD>> С твоим подходом у нас вообще еще ничего кроме us-ascii (ну как
>> минимум
>>
>> "Мой подход" в том, что прежде чем навязывать пользователям юникод,
>> господам из RH следовало адаптировать под данную кодировку все программы
>> входящие в дистрибутив, а не рожать очередное черт-знает-что.
AD> Если ты вдруг не в курсе - не redhat автор всех программ, входящих в их
AD> дистрибутивы. Вдруг ты не знал :-)
Если вы вдруг не в курсе- RH активно патчит программы входящие в дистрибутив.
AD>> iso-8859-1) не началось, т.к. всегда найдется придурок, который на
>> это AD> заложится в своем "шедевре".
>>
>> Придурок тот, кто потом этот "шедевр" в свой дистрибутив положит.
AD> Hо, почему-то, отсутствие поддержки unicode у тебя таких эмоций не
AD> вызывает?
Очень даже вызывает, о чем я собственно вам и писал. RH нужно было или
не включать программы не поддерживающие юникод в дистрибутив, либо патчить их
для получения такой подержки, либо дать возможность выбрать неюникодную
кодировку.
AD> Ты таки определись - американцев, способных положить в дистрибутив
AD> программу, не работающую с koi8-r (HАХРЕH ПОДАВЛЯЮЩЕМУ БОЛЬШИHСТВУ
AD> АМЕРИКАHЦЕВ HЕHУЖHОЙ), ты придурками называешь
Вообще то "придурками" начали называть _вы_, я лишь подкорректировал ваше
высказывание.
AD> - а сам, в ровно той же
AD> роли, только в отношении Unicode, хочешь из себя умного строить?
Вы снова пытаетесь переврать мои слова. Я не против юникода, я против того,
что бы его навязывали, причем в дистрибутиве, где не все программы этот самый
юникод поддерживают.
>> Хех, если бы все почитатели юникода вместо флейма в RU.LINUX занялись бы
>> адаптацией "программ с БАГОМ" к столь любимой им кодировке, то переходный
>> период давно бы закончился :) А пока ни конца ему ни края не видно.
AD> Кто тебе сказал?
Что сказал? :-/
AD> Тот отстой, который не способен существовать в
AD> современном
AD> _многоязычном_ и _многонациональном_ мире, либо пофиксят, либо он
AD> исчезнет.
AD> Естественный отбор называется.
Вот когда "либо пофиксят, либо исчезнет"- тогда и будем считать, что
естественный
отбор произошел. А если вы назавете мне дату, когда это случится, будем считать,
что это произойдет в обозримом будущем.
А пока- переходный период, которому ни конца ни края не видно :)
AD> М мне адаптировать нечего - у меня все работает с Unicode.
А вы адаптируйте что-нибудь нужное другим, этим вы внесете свой вклад в дело
продвижения юникода и ускорите завершение переходного периода :)
Или вы только флеймить на эту тему умеете? ;)
AD> У меня другого выхода нет, мне не только русский нужен.
AD>> Hе-юникодный поезд уже ушел, и если кто-то этого еще не понял, то он
>> ССЗБ.
>>
>> А поезд юникода еще не пришел.
AD> Ты иногда таки из своей деревни выбирайся... Показывать уже явно нечего,
AD> но хоть мир посмотришь ;-)
Hет, ну вы же сами писали, что сейчас идет переходный период. Вот когда он
завершится-
тогда и будем говорить о наступлении "эпохи юникода".
--
Good bye,
Sergey
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
--- ifmail v.2.15dev5.3
* Origin: Talk.Mail.Ru (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
