В продолжение темы о русской электронике...

[zyxman]

eng. Alex, вы про iapx 432 слышали? А про Itanium?
И чего, это по вашему не ошибки? Так уж не на чем учиться?

zyxman, возможно, вы слышали, но мы даже пользовались. iAPX 432 и Intnium были недоделанными до заявленного уровня процесорами, соответственные получились и результаты их продаж, хотя оба проекта были очень передовыми с точки зрения архитектуры и технологий.

Вы не умеете читать. Я прямо писал русским языком, что проблема "уникальных, не имеющих аналогов в мире технологий" не является уникальной для СССР/России - на создание никому не нужных технологий постоянно нарываются даже самые адекватные организации.

Двенадцатые смыслы ваших заявлений расопзнавать без ваших же комментариев не удается. Пишите яснее. Вы не писали про СССР/Россию, хотя возможно думали об этом. Проблема "уникальных технологий" не обсуждается, она и так общеизвестна. Речь идет о по-настоящему отсталых технологиях (x86), которые все (включая и Intel, и AMD) уже давно согласны поменять на нормальные (они уже даже разработаны), но из-за дележки денежного пирога (рыночная модель, кстати) весь мир продолжает ехать на хромой козе (64-разрядном расширении x86 сделанном AMD). Вы настаиваете, что тут нужно чему-то учиться.

Я следую контексту.
Вопрос в том, что клиент не согласен работать с полуфабрикатом ,коим является процессор без компилятора/без чипсета/без прикладного п/о, точнее КРУПНОкорпоративные клиенты в некоторых случаях могут потратиться на доведение полуфабриката до необходимого им внутри уровня, но этот полуфабрикат должен для этого быть очень перспективен.
Мало того - если у человека уже есть рабочий инструмент, то должна быть очень веская причина, чтобы он этот инструмент поменял, тем более чтобы за новый инструмент человек заплатил.
Другими словами - ЛУЧШЕЕ ВРАГ ХОРОШЕГО.

Учиться тут есть конкретно тому, как западные производители умудряются привязать массового клиента к своему продукту, при этом еще и находясь в условиях конкуренции.
Ну и собственно также нужно учиться и отвязыванию клиента от какого-то продукта и "перевязыванию" к новому продукту.

А у 432 и Итаниума проблема была в НЕДОоценке сложности задачи.

"Итаник" ещё всплывет, впрочем, для некоторых -- внезапно.

Пусть всплывает, мне не жалко. Но пока его потенциальное пространство захватил AMD_64.
Так что желаю вам сохранять ясность разума и не путать реальность и фантазии.

Причем тут реальность к потенциальному пространству? Itanium сейчас сидит в своей нише (высокопроизводительные системы)

Вы много знаете суперкомпьютеров на Itanium? Или что вы называете высокопроизводительными?

в нем заинтересованы клиенты и продолжают за него платить.

Ну всяко бывает. Но для реального бизнеса критично не само по себе наличие перспектив, а рост клиентской базы. А если роста нет то обязательно случится закат.

Основные конкурнты у него по-прежнему POWER и SPARC, а не AMD64.

Вы другие процессоры знаете? - Я к тому, что сейчас очень сильный конкурент именно на высокопроизводительных NEC ЕМНИП V8.
Кроме того прямо сейчас происходит революция перехода от вычислений чисто на универсальных ядрах к вычислениям на гибридных машинах CPU+GPU, и еще неизвестно, чем это закончится, кстати, позиции Intel в области высокопроизводительных вычислений на GPU не то что слабы а практически призрачны.

[zyxman]

тогда советую обратить внимание опять-таки на Эппл по ключевым словам LLVM и Clang с одной стороны и вспомнить о OpenCL и GC с точки зрения исполнения в динамической гетерогенной аппаратной среде с другой стороны. Ну или мириться с чудовищной неэффективностью жабы и иже с ней.  Ну и тривиальный Fat Binary никто не отменял.

Это известные и успешные упражнения, но их не используют в массовом (!) софте. Например, вы идете и покупаете (скачиваете) Office 64- или 32-разрядный, под x86 или ARM и т. п. То же самое действительно для Windows, Photoshop, Oracle, SQL Server и проч. Пока на рынке существует много "старого" софта, новым архитектурам дорога заказана -- они не нужны пользователям. Резкий переход невозможен (см. провал с попыткой перехода от x86 к IA-64), поэтому нужно обеспечить возможность запускать старый софт на новой архитектуре. В железе это раелизовывать дорого, поэтому всех перетягивают на промежуточный универсальный код, одновременно развивая при этом еще и инструменты и методы разработки.

Ваша проблема, что вы отталкиваетесь в своих рассуждениях от некорректной отправной точки.

Пользователю в общем случае по барабану что именно использовать - пользователю нужно решать его задачи.
И провал IA-64 случился СОВСЕМ НЕ ввиду сложности перехода, а ввиду того что AMD подсуетилась, и предложила AMD_64 раньше чем инсталляции IA-64 успели набрать критическую массу.

И еще, запомните или запишите себе - говорю как программист с очень порядочным опытом: таким архитектурам как IA-64 мало компилятора - там нужно и ЯВУ делать более высокой степени абстракции, чтобы в коде ЯВУ была информация, которую сможет использовать тот компилятор, а Java/C# имеют довольно низкую степень абстракции (чуть-чуть выше C), и поэтому сами по себе Java/C# НИЧЕГО не решат.

[eng. Alex]

/оффтоп
 ну имхо перетягивают на жабу не поэтому. Скажем так - фат бинари на 4 архитектуры достоверно используется с 2004 года массово, LLVM - где-то с 2008-2009, при этом от производителя софта в общем-то ничего не требуется.

Предлагаю вернуться к русской электронике )

Жаба уже плотно сидит в стандартах (например в DVB) и от нее не уйти, но технология виртульной машины оказалась проколом. Сейчас все равно стараются компилировать, хоть как-то, в родной бинарный код.

[zyxman]

/оффтоп
 ну имхо перетягивают на жабу не поэтому. Скажем так - фат бинари на 4 архитектуры достоверно используется с 2004 года массово, LLVM - где-то с 2008-2009, при этом от производителя софта в общем-то ничего не требуется.

На жабу перетягивают по той-же самой причине, по которой вместо Итаника в массы пошел амд-64 - Си устаревший, ограниченный инструмент, а предлагавшийся теоретиками ему на замену C++ слишком сложный и не решал все проблемы Си, и собственно Java была сделана точно для ниши Си - позволяла с минимальным переобучением работать тем-же людям.
LLVM честно серьезно не юзал, но думаю что это полумера - см выше - нужно уровень абстракции повыше чтоб было откуда информацию для оптимизации брать, хотя на какое-то время этого хватит.

Предлагаю вернуться к русской электронике )

Оно прямо относится к русской электронике - ей не хватает научиться делать то что людям будет нужно и они будут это покупать.

[eng. Alex]

Я следую контексту.
Вопрос в том, что клиент не согласен работать с полуфабрикатом ,коим является процессор без компилятора/без чипсета/без прикладного п/о, точнее КРУПНОкорпоративные клиенты в некоторых случаях могут потратиться на доведение полуфабриката до необходимого им внутри уровня, но этот полуфабрикат должен для этого быть очень перспективен.
Мало того - если у человека уже есть рабочий инструмент, то должна быть очень веская причина, чтобы он этот инструмент поменял, тем более чтобы за новый инструмент человек заплатил.
Другими словами - ЛУЧШЕЕ ВРАГ ХОРОШЕГО.

О полуфабрикатах вам было указано сразу же, когда вы вспомнили про 432 и "Итаник". Остальное -- общеизвестные истины.

Учиться тут есть конкретно тому, как западные производители умудряются привязать массового клиента к своему продукту, при этом еще и находясь в условиях конкуренции.
Ну и собственно также нужно учиться и отвязыванию клиента от какого-то продукта и "перевязыванию" к новому продукту.

Каков здесь уникальный метод привязывания и отвязывания? Чем он отличен от привязывания к молоку или пиву?

А у 432 и Итаниума проблема была в НЕДОоценке сложности задачи.

С задачей-то Intel в обоих случаях справился. Результат оказался не нужен заказчикам.

Причем тут реальность к потенциальному пространству? Itanium сейчас сидит в своей нише (высокопроизводительные системы)

Вы много знаете суперкомпьютеров на Itanium? Или что вы называете высокопроизводительными?

Причем тут суперкомпьютеры? Коммерческие системы HP на Itanium.

Ну всяко бывает. Но для реального бизнеса критично не само по себе наличие перспектив, а рост клиентской базы. А если роста нет то обязательно случится закат.

Может и случится закат, может рост появится. Перестанут покупать, продукт перестанут выпускать. Ничего экстраординарного.

Основные конкурнты у него по-прежнему POWER и SPARC, а не AMD64.

Вы другие процессоры знаете? - Я к тому, что сейчас очень сильный конкурент именно на высокопроизводительных NEC ЕМНИП V8.
Кроме того прямо сейчас происходит революция перехода от вычислений чисто на универсальных ядрах к вычислениям на гибридных машинах CPU+GPU, и еще неизвестно, чем это закончится, кстати, позиции Intel в области высокопроизводительных вычислений на GPU не то что слабы а практически призрачны.

Речь идет об процессорных архитектурах, а не процессорах как таковых. Гибридные машины появились от желания сэкономить, но работают они только на определенных счетных задачах. Существует же большой рынок DSP процессоров. Вот теперь появились аналогичные DSP суперкомпьютеры. Какая тут революция? Поищите ваш NEC в списке 500 быстрейших суперкомпьютеров (подсказка: 145 место).

[eng. Alex]

Ваша проблема, что вы отталкиваетесь в своих рассуждениях от некорректной отправной точки.

Ваша проблема, zyxman, в том, что вы считаете вашу точку зрения единственно возможной и верной. При этом вы не можете сконцентрироваться на ключевом вопросе. У вас широкий кругозор и это вас уводит в сторону от начального предмета дискусии. Поэтому сейчас приходится вам втолковывать про историю процессорных архитектур вместо того, чтобы узнать от вас, чему полезному можно было бы научиться у Хайфы (Интела в Израиле). Ведь это и был изначальный вопрос.

Пользователю в общем случае по барабану что именно использовать - пользователю нужно решать его задачи.
И провал IA-64 случился СОВСЕМ НЕ ввиду сложности перехода, а ввиду того что AMD подсуетилась, и предложила AMD_64 раньше чем инсталляции IA-64 успели набрать критическую массу.

На сложность перехода никто и не упирает. Стоит вопрос цены. Компании не желали переписывать и портировать на IA-64 кучу уже написанного софта, ведь это же -- огромные деньги. Поэтому даже Microsoft убедила Intel реализовать AMD64, который позволят пользоваться старым софтом. Причем, все понимают, что x86  -- отсталая архачиная архитектура.

И еще, запомните или запишите себе - говорю как программист с очень порядочным опытом: таким архитектурам как IA-64 мало компилятора - там нужно и ЯВУ делать более высокой степени абстракции, чтобы в коде ЯВУ была информация, которую сможет использовать тот компилятор, а Java/C# имеют довольно низкую степень абстракции (чуть-чуть выше C), и поэтому сами по себе Java/C# НИЧЕГО не решат.

Поменьше апломба, пожалуйста. Вы тут не едиственный умеющий программировать. О решениях каких задач вы тут пишете?

ЯВУ сам по себе не существует. ЯВУ бывает только в паре с его компилятором или интерпретатором, исполняющим в конечном итоге машинный код. ЯВУ с разметкой для компилятора -- образец понижения степени абстракции, а не ее повышения. ЯВУ -- для другого форума.

[Настрел]

Си устаревший, ограниченный инструмент, а предлагавшийся теоретиками ему на замену C++ слишком сложный и не решал все проблемы Си, и собственно Java была сделана точно для ниши Си - позволяла с минимальным переобучением работать тем-же людям.

Абсолютно каждое слово обратно по отношению к действительности. Зюхман, и как вам не надоедает постоянно позориться...

[zyxman]

Си устаревший, ограниченный инструмент, а предлагавшийся теоретиками ему на замену C++ слишком сложный и не решал все проблемы Си, и собственно Java была сделана точно для ниши Си - позволяла с минимальным переобучением работать тем-же людям.

Абсолютно каждое слово обратно по отношению к действительности. Зюхман, и как вам не надоедает постоянно позориться...

Если у вас есть аргументы и/или факты, опровергающие мою точку зрения - излагайте.
Пока что я вижу только совершенно неоригинальные эмоции

[zyxman]

Ваша проблема, что вы отталкиваетесь в своих рассуждениях от некорректной отправной точки.

Ваша проблема, zyxman, в том, что вы считаете вашу точку зрения единственно возможной и верной. При этом вы не можете сконцентрироваться на ключевом вопросе. У вас широкий кругозор и это вас уводит в сторону от начального предмета дискусии. Поэтому сейчас приходится вам втолковывать про историю процессорных архитектур вместо того, чтобы узнать от вас, чему полезному можно было бы научиться у Хайфы (Интела в Израиле). Ведь это и был изначальный вопрос.

А вот это пожалуй главная проблема русской электроники, что вот такие как вы, вместо того чтобы признать свою ошибку, пытаетесь демагогическими и политическими приемами доказать неправоту собеседника.
То что вы не умеете продавать уже вторично - нельзя научиться продавать на свободном рынке, не умея признавать свои ошибки.
Евреи кстати умеют проигрывать.

Конкретно по теме, внесение разметки в код это действительно не повышение уровня абстракции - сразу видно что вы с современными системами программирования не знакомы.
А повышением уровня абстракции является переход от физического уровня к более высокоуровневым абстракциям, например:
самый нижний уровень машинный код скажем 8080, в котором ЕМНИП нет например базовой адресации и один аккумулятор - код 68000 уже работал с несколько более высокими уровнями абстракции, тк там 8 базовых регистров и регистров общего назначения аж 8 штук, и есть команды позволяющие прямо перевести в код ОДНОЙ машинной команды типичную для Си конструкцию типа arr[a++] = arr2[b--] и таким образом довольно гибко и просто реализовать высокоуровневые структуры fifo, lifo; еще меньше уровень абстракции у канонических RISC, которые принципиально шли на отход от идеологии "одно выражение ЯВУ стремится к одной инструкции";
а были например Лисп-машины, у которых абстракции ЯВУ Лисп обрабатывались микрокодом (кстати, на похожей технологии когда-то реализовали Ява-процессор);

Более высокий уровень абстракции (чем простейший ассемблер), это процедурное императивное программирование, такое как Си - там уже встроены в язык конструкции работы с функциями и с различными типами данных и плюс в язык встроена обертка проверки корректности обращения к данным;
Еще более высокий уровень объектное программирование на императивных языках - суть в том что мы обращаемся к объекту как к черному ящику, внутри которого может быть что-то очень сложное;
Где-то на уровне чуть выше объектного программирования находится уровень функциональных языков, в которых уже почти всегда встроены такие структуры как fifo, lifo, векторы (массивы), хэши, есть возможность строить иерархические структуры хэши хэшей, хэши массивов, и тп в разных комбинациях, и также данные как правило динамические и есть автоматический сборщик мусора (я лично кроме 432 не знаю ни одной архитектуры с поддержкой сборки мусора на физическом уровне процессора, даже на Лисп-процессорах сборку мусора делали чисто программно);
Вообще рекурсия, на которой базируются функциональные языки, это очень богатая конструкция, которая позволяет строить практически какие угодно операторы, и некоторые из этих операторов уже стандартизированы - например, для функциональных языков более-менее типично встроенная прямо в язык возможность прямого сравнения сложных иерархических структур данных

Вместе с функциональными языками начинается уровень декларативного программирования - когда программист НЕ пишет КАК именно машина должна выполнить его указания, а программист пишет только что должна сделать машина - например декларативный SQL - там для запроса не нужно знать внутреннюю структуру СУБД, хотя в некоторых случаях для оптимизации и приходится выходить за рамки чистой математики и подгонять под конкретную реализацию СУБД;
есть альтернативный подход - в Аде декларативность применяется не в программировании а в тестировании и в разграничении доступа, что конечно тоже полезно но как раз ближе к вставке в ЯВУ разметки;
еще вариант, языки узкоспециализированные для какой-то предметной области - например, HTML вполне себе язык, в котором уже абстракции идут на уровне декларации разметки текста, а есть язык xslt, на котором даже можно программировать; еще к таковым узкоспец языкам я отношу Пролог - у него встроена в язык типичная для технологий ИИ операция перебора с возвратом (а в Лисп реализацию этого написали на самом языке, пользуясь гибкостью функционального языка).

Конкретно для случая многопотоковых машин, есть языки, позволяющие явно указать потоки - например, весьма удачный многопотоковый язык Эрланг (он в какой-то мере развитие идеологии Смоллтолка, в том что "объекты" Эрланга как и у Смоллтолка передают и принимают информацию сообщениями, но плюс могут находиться на разных процессорах и даже разных машинах и плюс "объекты" Эрланга живут асинхронно с приемом и передачей сообщений).

Кстати, да, есть вариант сделать виртмашину, которая будет реализовывать более высокий уровень абстракции чем дает физический уровень, и таким образом сделать по сути высокоуровневый машкод, но компилятор в любом случае должен где-то узнать об этой абстракции, и лучше всего, если он узнает прямо из использования в коде ЯВУ каких-то далеких от физуровня абстракций.

[eng. Alex]

А вот это пожалуй главная проблема русской электроники, что вот такие как вы, вместо того чтобы признать свою ошибку, пытаетесь демагогическими и политическими приемами доказать неправоту собеседника.
То что вы не умеете продавать уже вторично - нельзя научиться продавать на свободном рынке, не умея признавать свои ошибки.
Евреи кстати умеют проигрывать.

Тогда проигрывайте, чего уж тут...

...говорю как программист с очень порядочным опытом: таким архитектурам как IA-64 мало компилятора - там нужно и ЯВУ делать более высокой степени абстракции, чтобы в коде ЯВУ была информация, которую сможет использовать тот компилятор...

Конкретно по теме, внесение разметки в код это действительно не повышение уровня абстракции - сразу видно что вы с современными системами программирования не знакомы.

Излияния вашей души оставим потомкам. Нам они ни к чему. Ну и вы с собой сперва договоритесь о дополнительной информации для компилятора в ЯВУ, а то ваши противоречивые суждения заводят в тупик. А как вы выводите второе утверждение (о знакомстве с системами программирования) из первого (внесение разметки -- не повышение уровня абстракции), вообще нормальному человеку непостижимо.

[zyxman]

...говорю как программист с очень порядочным опытом: таким архитектурам как IA-64 мало компилятора - там нужно и ЯВУ делать более высокой степени абстракции, чтобы в коде ЯВУ была информация, которую сможет использовать тот компилятор...

Конкретно по теме, внесение разметки в код это действительно не повышение уровня абстракции - сразу видно что вы с современными системами программирования не знакомы.

Излияния вашей души оставим потомкам. Нам они ни к чему. Ну и вы с собой сперва договоритесь о дополнительной информации для компилятора в ЯВУ, а то ваши противоречивые суждения заводят в тупик. А как вы выводите второе утверждение (о знакомстве с системами программирования) из первого (внесение разметки -- не повышение уровня абстракции), вообще нормальному человеку непостижимо.

Гибкости ума вам явно не хватает.
Никакого противоречия - когда программист оперирует машинными словами и битами это нижний уровень абстракции, а когда иерархическими структурами, объектами и компонентами, это высокий уровень абстракции.
Пример высокого уровня абстракции, когда я посылаю окну сообщение-команду "обновиться", скажем так:
Window_pid ! "обновиться";
пример низкого уровня абстракции, когда я пишу код типа (очень упрощенно):
for (i=0; i = buffer; }

Соответственно, для высокого уровня абстракции система (компилятор+линкер+ядро или виртмашина), обрабатывает сама всю "магию" и может использовать заранее тщательно оптимизированный код (неважно как именно он был оптимизирован, вручную написан оптимально, или механическим перебором вариантов с выбором наилучшего).
Даже может быть вариант (и собственно, при капитализме часто так происходит), что уже после того как я напишу высокоуровневый код, программа совсем без моего участия в какой-то момент станет работать быстрей, просто потому что компонент, который я использую был обновлен производителем компонентов и у меня в системе автоматически установился новый, лучше оптимизированный компонент.

[Scarecrow]

Простите, у вас двоих просто недоразумение при прочтении взаимных текстов, о причинах своё имхо говорить не буду, но так неинтересно читать, если не наслаждаться срачем. Прошу, замните для ясности. (Просто в шутку: зухман, Вы что, считаете что eng.Alex динозавр из эпох алголя и паскаля?)

[zyxman]

Простите, у вас двоих просто недоразумение при прочтении взаимных текстов

Ну вобщем да. Хотя есть и некоторая разница позиций - я с некоторых пор исхожу с позиции, что главное не продвинутость технологий а продажи.
Естественно, это означает что в какой-то момент необходимо вложиться и раньше конкурента вывести на рынок новую, более продвинутую технологию, но в общем случае не может быть единства в прогнозе, когда именно наступит этот момент. Даже смотря постфактум не факт что будет единое мнение, был ли момент вовремя или рано или поздно.
Так же часто в общем случае непросто и с вопросом выбора, какую именно технологию двигать.

[Scarecrow]

Ну это понятно, я о "уровнях абстракции".

[eng. Alex]

Гибкости ума вам явно не хватает.

zyxman, вам, скорее, не хватает сосредоточенности и умения общаться. Вы делаете слишком много предположений и исходя из них строите свои рассуждения. Будьте внимательны к сообщенным вам фактам.

...говорю как программист с очень порядочным опытом: таким архитектурам как IA-64 мало компилятора - там нужно и ЯВУ делать более высокой степени абстракции, чтобы в коде ЯВУ была информация, которую сможет использовать тот компилятор...

Никакого противоречия - когда программист оперирует машинными словами и битами это нижний уровень абстракции, а когда иерархическими структурами, объектами и компонентами, это высокий уровень абстракции.
Пример высокого уровня абстракции, когда я посылаю окну сообщение-команду "обновиться", скажем так:
Window_pid ! "обновиться";
пример низкого уровня абстракции, когда я пишу код типа (очень упрощенно):
for (i=0; i = buffer; }

Соответственно, для высокого уровня абстракции система (компилятор+линкер+ядро или виртмашина), обрабатывает сама всю "магию" и может использовать заранее тщательно оптимизированный код (неважно как именно он был оптимизирован, вручную написан оптимально, или механическим перебором вариантов с выбором наилучшего).
Даже может быть вариант (и собственно, при капитализме часто так происходит), что уже после того как я напишу высокоуровневый код, программа совсем без моего участия в какой-то момент станет работать быстрей, просто потому что компонент, который я использую был обновлен производителем компонентов и у меня в системе автоматически установился новый, лучше оптимизированный компонент.

Вы понимаете COM. Отлично! Вернемся все же к вашим идеям. Что же все-таки с дополнительной информацией для компилятора? Продемонстрируйте ее на вашем первом (высокоабстрактном) примере.

[eng. Alex]

Простите, у вас двоих просто недоразумение при прочтении взаимных текстов, о причинах своё имхо говорить не буду, но так неинтересно читать, если не наслаждаться срачем. Прошу, замните для ясности. (Просто в шутку: зухман, Вы что, считаете что eng.Alex динозавр из эпох алголя и паскаля?)

Пожалуй, стоит уже прекратить, ибо у меня появилось чувство, будто общаюсь с радиоприемником.

[eng. Alex]

Простите, у вас двоих просто недоразумение при прочтении взаимных текстов

Ну вобщем да. Хотя есть и некоторая разница позиций - я с некоторых пор исхожу с позиции, что главное не продвинутость технологий а продажи.
Естественно, это означает что в какой-то момент необходимо вложиться и раньше конкурента вывести на рынок новую, более продвинутую технологию, но в общем случае не может быть единства в прогнозе, когда именно наступит этот момент. Даже смотря постфактум не факт что будет единое мнение, был ли момент вовремя или рано или поздно.
Так же часто в общем случае непросто и с вопросом выбора, какую именно технологию двигать.

Процитируем кое-что еще раз, а то уже по всей видимости оно забылось:

И выигрывает тот кто лучше умеет продавать.

Технологии не важны, а важно то, что выделено желтым.

[sychbird]

Ну  за этим могут скрываться две достаточно расхожие идеи, ИМХО.
Первая говорит о приоритете закулисных сделок со взаимными неафишируемыми обязательствами сотрудничества и общей маркетинговой и технологической поддержке в борьбе за определенные рыночные ниши.

Вторая - в том, что доведение новой технологии до необходимого качества дело затратное, и первым успевает это сделать не тот, кто имеет лучшую технологию, а тот у кого окажется больше финансовых ресурсов для выполнения этой задачи. А кто успел первым, тот и съел большую часть пирога.

[Старый]

Пожалуй, стоит уже прекратить, ибо у меня появилось чувство, будто общаюсь с радиоприемником.

Долго же оно у вас появлялось. Похоже вам действительно "не хватало гибкости ума" (с) зюхман.

[eng. Alex]

Пожалуй, стоит уже прекратить, ибо у меня появилось чувство, будто общаюсь с радиоприемником.

Долго же оно у вас появлялось. Похоже вам действительно "не хватало гибкости ума" (с) зюхман.

Старый, у меня терпения много, но не столько сколько у вас.

Ведь тут он в своей области, вроде как. Чистый эксперимент получился. Ну прямо лабораторное исследование.