> угу. autotools hell: "проект не собирается, но после применения в определенной последовательности гнутых автотулз определенных версий, появляется небольшой шанс что сборка пройдет успешно".

> это не треп, *действительно* часто имеет значение конкретная версия autoconf/automake. потому и придумывают как одновремено держать несколько разных и рулить ими.

Это уже не смешно. Это грустно. :(

Видишь ли для сборки проекта сделанного на основе autotools не нужны сами autotools. Нужны результаты их использования.

Разницу чувствуешь?

>Пиши со сокростью мысли, кто против. Позрослеешь -- поймёшь, что ЭТО >надо ещё и отлаживать и главное, поддерживать и развивать. Gleb, специально для таких идиотов как ты я в конце написал, что поддерживаю и развиваю Perl проекты уже 4 года или краснота глазам уже мешает??

>О числе ошибок и уязвимостей в перл-коде, вообще говорить неприлично Какие нахрен уязвимости??? Ошибки ты делаешь сам и это твой личный показатель. use strict и "мозг ON" всегда спасал.

>А питона ты не знаешь. Иначе не порол бы чушь о "детском поделии", а >как минимум, указал бы на равномощность перла и питона, за исключением >того, что питон изначально был сконструирован как >объектно-ориентированный и сразвитой системой отслеживания ошибок. Я не считаю Питон равномощным Perl-у, единсвенная интересная фишка в Питоне - объектная ориентированность, что легко покрывается классами Perl, а исключения конструкцией eval, к этому быстро привыкаешь, если мыслить в стиле Perl. Вот как будет в Питоне аналог CPAN, вот тогда поговорим, а пока детское поделие и точка.

>А эклетическая смесь стилей и птичьего языка в перле Пионерская отмазка, так бы и сказал - "ниасилил" :) На этом "птичьем языке" гораздо проще изложить мысль. Главное понять идеологию Лари, и тогда все становится интуитивным, просто со времением вникаешь и все.

Мне в питоне нравится наличие wxPython и RAD к нему. Собственно, счас изучаю - нравится.
После перла - прям дзен какой-то.
Хотя, штоб перелопатить текстовые таблицы на миллионы строк - я возьму перл или даже plain C.
Но вот морды для запросов и отчётов для зоопарка баз данных, серверов приложений и для разных платформ - тока wxPython... Рулез немерянный.

>Хотя, штоб перелопатить текстовые таблицы на миллионы строк - я >возьму перл или даже plain C. >Но вот морды для запросов и отчётов для зоопарка баз данных, серверов >приложений и для разных платформ - тока wxPython... Рулез немерянный.

Истинно так. Только перед тем как писать что то на plain С. Почитай сперва про такую вещь как Pyrex, вдруг и на plain c писать не придётся ;D

>ЗАЧЕМ НА СЕРВЕРЕ КОМПИЛЯТОР? подрастешь, начнешь админить сервер, поймешь

я уже понял :) чтобы кулхацкерам было чем эксплойты компилять, да?

если ты сборку делаешь непосредственно на сервере - это значит у тебя сервер ровно один. иначе ты собрал бы *один раз* в пакет и раскидал.

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

итак. какие задачи решают твои сервера если на них постоянно необходим компилятор?

>Видишь ли для сборки проекта сделанного на основе autotools не нужны сами autotools. Нужны результаты их использования.

я в курсе. видишь ли, для сборки проекта с использованием scons сборка самого scons и питона не требуется. нужен рантайм - python24.so.

єто раз. а второе - если тебе нужно вмешаться в сборку (а готовые ./configure бывают настолько кривы, что диву даешься - чем их генерили) - так или иначе придется задейстовавать autotools для генерации сборочной системы проекта (Можно править готовые configure / Makefile, но проще удавиться)

Еще тебе иногда *придется* делать libtoolize --copy --force.

>> отучиваемся п..ть и тащим примеры в студию. я пересобрал не одну сотню пакетов, проблем никогда не было

> отучаемся делать широкие обощения на основании своей сугубо местечковой кочки зрения.

> Всё остальное -- $50/час :)

> /GLeb

Опять хохлы нас жизни учат...

> Главное понять идеологию Лари, и тогда все становится интуитивным, просто со времением вникаешь и все.

Насколько я помню, Лари -- профессиональный лингвист.

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

P.S. Иногда, сложно, но красиво. :)

> для таких идиотов как ты я в конце написал, что поддерживаю и развиваю Perl проекты уже 4 года или краснота глазам уже мешает??

И какие это проекты?

> Вот как будет в Питоне аналог CPAN

Parnassus

> А эклетическая смесь стилей и птичьего языка в перле Пионерская отмазка,

Нет, это эклетическая смесь

>так бы и сказал - "ниасилил" :)

таки повзрослей

> Лари -- профессиональный лингвист.

боже ж мой...

> P.S. Иногда, сложно, но красиво. :)

о нет, сложно -- нет. кратко -- да. запутанно -- да. Красиво? Никогда!

>>Опять хохлы нас жизни учат...

fuck off

> я в курсе. видишь ли, для сборки проекта с использованием scons сборка самого scons и питона не требуется. нужен рантайм - python24.so.

Ну держите меня, я счас лопну от смеха. Ж:) Ты так придуриваешься или издеваешься. Именно про то что нужен рантайм я и говорил. И если присмотришься у него и номер версии есть. Что подразумевает, что при смене версии он может быть несовместим. В сад! Однозначно! А тех кто пытается пропогандировать хаки на учебу!

> И если присмотришься у него и номер версии есть. Что подразумевает, что при смене версии он может быть несовместим. В сад! Однозначно! А тех кто пытается пропогандировать хаки на учебу!

Извини, дружище, но ты упёртый дурак. Рантайм есть *у всего*. В то же время, смена версии языковой системы, НЕ ПРЕДУСМАТРИВАЕТ СМЕНЫ ЯЗЫКА.

>Именно про то что нужен рантайм я и говорил.

интересно. а perl рантайм тебе не нужен? и вопсче: почему это я должен ставить make только ради сборки одного проекта?

>И если присмотришься у него и номер версии есть. Что подразумевает, что при смене версии он может быть несовместим.

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

glibc2.2 vs 2.3

gcc3.3 vs 3.4. qt проекты компилировать именно тем компилятором которым собиралась libqt. ну?

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

Да, понятно. Это ты так прикалываешься. :)

Лучшей довод: У них говно, так что и нам можно говница добавить. Делаем мозги off И не замечаем что без дополнительного говна можно обойтись.

Если несовместимости компиляторов есть, то они обходятся autotools. Он для этого и придуман.

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

Странные у тебя учителя физики, анонимус Глеб. Так тебя и не научили, что скорость, это фундамент, на котором строиться все остальное. Она сама по себе. Какое может быть у нее граничное условие ? Ты и программер такой же как физик, или все таки лучший ? Смею надеяться, что лучший.

Любое решение для С(++), ограничивающее скорость сборки, это частное решение. Нечто, написанное на питоне, не может не ограничивать скорость сборки, по сравнению с чем то, написанным на С(++). Конечно реализация может быть такой, что все может быть наоборот, но речь о принципе.

>Любое решение для С(++), ограничивающее скорость сборки, это частное решение. Нечто, написанное на питоне, не может не ограничивать скорость сборки, по сравнению с чем то, написанным на С(++)

ну ты реально жжошь. паузы между вызовами gcc увеличиваются, что ли? 98% cputime занятого сборкой, отгрызает собственно компиляция и линковка.

>скорость, это фундамент, на котором строиться все остальное. Она сама по себе

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

>Так тебя и не научили, что скорость, это фундамент, на котором строиться все остальное. Она сама по себе.

>Любое решение для С(++), ограничивающее скорость сборки, это частное решение. Нечто, написанное на питоне, не может не ограничивать скорость сборки, по сравнению с чем то, написанным на С(++). Конечно реализация может быть такой, что все может быть наоборот, но речь о принципе.

Н-да. даже не знаю, плакать, смеяться или... гм... адекватно отреагировать. Ладно, будем взаимно вежливы. Доступно для твоего понимания :) : Вспомни правило рычага: "проигрывая в расстоянии, выигрываем в силе. И наоборот." Вспомнил? Теперь сходи, проспись как следует.

/GLeb

> Если несовместимости компиляторов есть, то они обходятся autotools. Он для этого и придуман.

???? Куда смотрит госнаркоконтроль? Такую траву при всём честном народе?!

/GLeb

> ???? Куда смотрит госнаркоконтроль? Такую траву при всём честном народе?!

Может быть ты не вкурсе, но autotools придуманы для обхода несовместимостей. Есть там и проверка на компилятор. Плюс можешь понаписать тестов сколько душе угодно. Плюс взять уже существующие. И в зависимотси от этого можно включать разные макросы или разные реализации. Учи матчасть. Прежде чем начнешь еще что-либо советовать кому-либо, на полном серьезе, советую подучить матчасть. А вчастности прочитать хотябы книжку про autotools.

> Есть там и проверка на компилятор. Плюс можешь понаписать тестов сколько душе угодно.

А то я не знаю.

> И в зависимотси от этого можно включать разные макросы или разные реализации.

Которые я должен создать руками, ЗАРАНЕЕ ЗНАЯ О ВОЗМОЖНЫХ ВАРИАНТАХ. автотулзы за меня, соответствующий код не напишут. И где здесь обход? Это варианты выбора, отнюдь не "обхода".

> А вчастности прочитать хотябы книжку про autotools.

спасибо, обойдусь.

/GLeb

> автотулзы за меня, соответствующий код не напишут.

Нет, конечно. Не напишут.

А кто напишет? Видишь ли кто-то написать должен.

Но, возможно уже написали другие. Залезаешь в библиотеку макросов и смотришь что есть. Если нет то ручками.

>> автотулзы за меня, соответствующий код не напишут.

>Нет, конечно. Не напишут.

>А кто напишет? Видишь ли кто-то написать должен.

>Но, возможно уже написали другие. Залезаешь в библиотеку макросов и смотришь что есть. Если нет то ручками

А ты не понимаешь, что сам себе противоречишь и весь твой тезис, таким образом, превращается в пустой трёп -- лишь бы что сказать?

/GLeb

2 анонимус Глеб

Я выполнил все твои советы - проспался, помедитировал, помолился - так как обы4ые способы успокоения уже не помогают - смех мне уже не доставляет удовольствия.

Я не понял почему ты смешься или плачешь. Но твои учителя рыдают - скорее от смеха, но некоторые от обиды. Потому как на том уровне физики, на котором скорость это фундамент физики, а выше этого уровня физика еще не поднялась (скажу тебе по секрету), про рычаги не говорят - не из той оперы.

Между пониманием важности рычага, и пониманием его несущественности для мироздания, и пониманием важности для этого мироздания именно скорости - прошло лет наверное 200. Тебе это ни о чем не говорит ?

Надеюсь ты все понял, что я хотел сказать.

pardon

предыдущий пост был мой, это был argin, не anonimous

:-)

Н-да... трава нынче -- супер, сразу стадия разжижения мозгов, минуя стадию кайфа.

/GLeb

>никакой иной реакции судя по треду от тебя и не ожидалось. как же, задели твою священную корову - "пистон в каждый дом" :)

Наверное, поздновато отвечаю :). Какой ответ ты еще ожидал? Насчет Питона ты не прав - мне он, в общем-то, монопенисуален. Я не являюсь фанатом этого языка. Мне нужно было написать простенький парсер, поставил Питон, написал. В общем-то никаких проблем.

Мне просто интересно, какие могут быть внятные технические аргументы против его установки. Желательно с отрицательными примерами - что от него возникает плохого.

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

Второй аргумент, приходящий в голову - сложность установки и поддержки. Для меня этот аргумент тоже имеет малый смысл, в силу особенностей используемого дистрбутива :) Хотя, конечно, не исключаю, Debian не единственная ОС.

Бывают какие-то еще аргументы?

Есть, конечно, вероятность, что злоумышленник использует его для своих целей. Ну там скриптик какой запустить, уже имея нужный доступ. Ну так он и на Перле такое же сочинить может.

В общем, я решительно не понимаю, какие могут быть _технические_ аргументы против установки Питона (ну, кроме упомянутых) на сервер. Все что я пока слышал - эмоции. "Как?! Питон? На сервер? Да вы с ума сошли!!"

Трава это последний довод ?

Я искренне сожалею, что так и не сумел до тебя довести, что скорость исполнения это ОЧЕМЬ важный параметр. Я использовал для этого примеры из области твоего оригинального образования. Я специально пытался выражать свои мысли, используя чисто физический язык.

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

Теперь о другом. Шелл это интерпретатор, и в нынешней схеме компиляции С(++), все равно используется интерпретируемый язык( а шелл это и язык), а питон хоть пытается быть быстрым, за счет байт кода ...

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

Спорить, это не означает непрерывно возражать.

Все, что устанавливается на сервер, должно быть оттестированно на устойчивость к взлому, стабильность и надежность, гибкость и скорость это еще не все (для серваков). Что скажете на эту тему?

>Все, что устанавливается на сервер, должно быть оттестированно на устойчивость к взлому, стабильность и надежность, гибкость и скорость это еще не все (для серваков). Что скажете на эту тему?

Согласен с одним "но". С моей ламерской точки зрения имеет смысл тестировать только имеенно конечные сервисы - т.е то, с чем взаимодействует конечный пользователь. А так же "группу риска" - сетевые сервисы, suid-ные программы, ядро, libc, и.т.д.

И с моей точки зрения Python/SCons (в данной ситуации) ни в одну из этих категорий не попадает. Разве что косвенно - возможна ситуация, что из-за кривой реализации системы сборки конечный софт соберется криво (или медленно) и будет содержать ошибки.

Мне кажется, эта ситуация маловероятна (хотя так просто отвергнуть этот аргумент уже не получится - нужна статистика, я не знаю, насколько надежен в этом плане SCons). Ну а если про собственно Python говорить, я думаю, он уже может считаться вполне надежным.

Так или нет?

> А ты не понимаешь, что сам себе противоречишь и весь твой тезис, таким образом, превращается в пустой трёп -- лишь бы что сказать?

Уточни в чем. Библиотека макросов используется разработчиками и она не нужна пользователю. Пользователи пользуются лишь результатами их работы.

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

А.... Понял.

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

> Ты не знаешь принципов функционирования autotools. Не знаешь чем он принципиально отличается от предложенной тобой системы сборки.

да нет, знаю. Знаю, почему для autotools нужны (н были бы нужны, не приделывали бы!) дополнительные костыли (*libs), слшком хорошо знаю, как часто не удаётся собрать проект, конфигурируемый аутотулзами.

Наверное, знаю не только я :), раз существует несколько (именно несколько, то есть, н одному какому-то придурку не угодили автотулзы!) проектов альтернативных, более интеллектуальных систем сборки.

Короче, мне уже не интересно и право, надоело. Попробуй, для начала, сам ознакомиться со сконсом (как, наверное, самым удачным представителем проектов интеллектуальных сборщиков) и закладываемой в него идеологией.

PS: функциональнность автотулз, в него закладывается. *Пока*, она реализована не полностью, но закладывается и делается.

Что качается большинства -- это не аргумент. Всегда нужно разбираться в предмете дискуссии, и делать свои выводы -- для себя. Большинство до сих пор использует чистый фортран для расчётных задач и выпадает в мелкий осадок, когда наблюдает что та же самая задча на ++ с соответствующей мат. классовой библиотекой не только пишется и отлаживается существенно быстрее, но и выполняется ничуть не медленнее. Но переучиваться -- не хочется. Ну и что? Призказку по Буратино -- не сегодня придумали.

/GLeb

>> А ты не понимаешь, что сам себе противоречишь и весь твой тезис, таким образом, превращается в пустой трёп -- лишь бы что сказать?

>Уточни в чем. Библиотека макросов используется разработчиками и она не нужна пользователю. Пользователи пользуются лишь результатами их работы.

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

/GLeb

>Трава это последний довод ?

Нет. но каак-то же надо реагировать на чушь, находясь в рамках приличий?

>Я искренне сожалею, что так и не сумел до тебя довести, что скорость исполнения это ОЧЕМЬ важный параметр.

Кто-то спорит?

>Я специально пытался выражать свои мысли, используя чисто физический язык.

Ну что же... могу только повториться -- учите физику -- мать вашу!

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

Возможно, физику я знаю и плохо, хотя на работе (пока) держат. Хорошо, давай на пальцах.

1. нет такого понятия -- "важнее ничего нет". Тем более, если ты пытаешмя ввести *некую*, асбтракную, "скорость" -- "в основание всего". О какой "скорости" ты говоришь? О классическом понятии? Тогда непонятно, по определению, скорость (в книнематике) есть производная радиус-вектора точки по времени, dr/dt. Вторичная, производная величина -- никак не базовая. Если ты имеешь в виду C, как фундаментальную константу, то это не просто какая-то абстрактная скорость, это вполне конкретная вещь: пределная скорость распространения физических взаимодействий в физическом вакууме, как отражение фундаментальных свойств пространства. В частности, связывает массу и полную энергию материального тела. Заметь, C -- опять не некая "скорость" сама по себе, а показатель *взаимодействия* материальных объектов погружёрных в наше, наблюдаемое пространство. И строго говоря, природа этого взамодействия, неизвестна. В СТО, постоянство C просто постулируется (хотя есть вывод этого дела через законы сохранения, или наоборот, если угодно). Даже более того, есть сомнения в том, что C -- константа, есть астрофиический эксперимент, позволяющий предположить, что C уменьшается с течением времени. В любом случае -- это число есть отражение фундаментальных свойств мироздания и сама по себе, без осознания того факта, что C есть мера скорости передачи взаимодействия, не более ценна, чем дырка от бублика! Даже постулат о инвариантности C относительно выбора системы отсчёта может оказаться лишь приближением при переходе к рассмотрению пространств с высокой размерностью, а наше пространство сейчас склонны рассматривать именно как 12-и мерное (впочем, это не ко мне, я не теоретик, могу и завраться, так что не будем. Основной тезис -- понятен!).

Ну и наконец, даже в такой прикладной вещи, как обыкновенное программирование, ни о какой "абсолютной ценности скорости" не тдёт и речи: в зависимости от задачи, может быть более выжным экономия памяти, за счёт падения скорости вычисления, либо экономия других ресурсов, опять-таки, за счёт падения скорости. Даже более того, задача может быть вообще практически нереализуема, если не пожертвовать максимально возможной скоростью в ущерб экономии памяти. Пример? Да наздоровье, самый примтивный: вычисления моделей, приводящих к генерации больших матриц. Попытка добиться максимально возможной скорости за счёт размещения матриц в ОЗУ приведёт просто к исчерпанию всех возможных видов памяти...

Вообще, любая задача, если в её условиях не оговорены граничные условия -- бессмыслена и не имеет решения! Постарайся это понять.

Точно так же и здесь. Да, применяя интерпретатор, поригрываем в скорости выполнения -- но выполнения чего? В скорости выполнения кода сборочной системы. Волнует нас это -- да ничуть. Собственно сборка -- вызов компилятора, ликовщика., прочих доп. средств, занимает 99.9% процессорного времени, на долю сборочной системы приходится, дай бог, 0.1%. Можно положиь всю жизнь на достижения максимально возможной скорости и уменьшить потребление поцессора на 0.05%, в резултьтате, проект станет собираться на долю секуны меньше. Ну и кому это было нужно? Зато теряем возможность гибко настраивать систему сборки. Как в том примере с рычагом -- выиграли в скорости, поиграли в функционале.

Теперь дошло?

PS: И не надо ставить в пример вещи, в которых нифига не смыслишь. Заявил бы ты мне на экзамене, мол скорость -- фундамент всей физики, ага.

> Все, что устанавливается на сервер, должно быть оттестированно на устойчивость к взлому, стабильность и надежность, гибкость и скорость это еще не все (для серваков). Что скажете на эту тему?

Питон (CPython, естественно) весьма тщательно тестируется и изестные дыры в безопасности, достаточно опертивно фиксятся.

Наконец, обрати внимание на такую замечательную вещь, как Zope: чистый питон на web-сервере. Естетственно, дыры также обнаруживаются и оперативно затыкаются.

/GLeb

>зачем на сервере perl ади сьорки пары проектов? для тех кто в танке - без перла автотулзы не работают.

Ты о чём вообще? Сама сборка спокойно без перла идёт! Шёл бы на горшок ваапче, а то в пионер-вожатый дюлей вставит!

>Вот когда ошибки в перловых скриптах станет возможно видеть сразу и появится возможность возобновлять проект через пол-года -- год после последнег обращения, не переписывая всё "с нуля" -- тогда поговрим.

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

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

Может быть я и туплю, но не объяснишь ли ты мне, каким именно образом мои аргументы идут лесом. Я что-то не замечаю ничего их опровергающего. Ни в своих ни тем более в твоих постах. Покажи конкретно где и что. Серьезно. Желательно по пунктам разложить. А то боюсь простого намека не пойму.

2 анонимус Глеб

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

То, что ты говоришь, как ты споришь, как слушаешь, как аргументируешь, вполне тебя характеризует.

Скорость света в вакууме пока еще краегольное понятие в физике, и от этого никто пока не отказался. Это постулат(в физике). А для собственно предмета разговора, просто иллюстрация важности этого понятия.

Язык С(++) спроектирован для максимальной эффективности, а скорость тоже входит в это понятие.

Это мое основное положение, а выводы и рассуждения - это то, что питон не должен влиять на скорость, и для него приемлимо заменять нишу шелла(баша), а не make .

Ты пытаешься опровергнуть не вывод, даже не посылку, а иллюстрацию , так делают все плохие спорщики.

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

Я попробовал сделать ясной и понятной для всех мою точку зрения, но я отнюдь не имею цели кого либо убеждать в ее правоте. Так как я хотел для себя что то прояснить, я реально это сделал, и моя точка зрения развивалась и заняла уже вполне определеную позицию.

Надеюсь она кому то покажется интересной, всем кто мне оппонировал - спасибо, вы мне помогли фактом своего опонирования, но хотелось бы сосредоточиться на существе проблемы , а не на деталях

P.S 2 анонимус Глеб

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

афтар пищи еще! Эх луговского бы сюда :) Два физика бы поняли друг друга...

>я знаю професионально ^^^^^^^^^^^^^^

i see, ага