МикроБЭСМ-79

[Marlagram]

Вот кстати, меня как не заставшего те славные времена всегда интересовало - а зачем он был именно такой? Были какие-то определенные задачи, или это был какой выпендреж?

Задача поначалу - ПРО. При том не абы как - а надо было закопать конкурентов с СОК-машиной весьма немалой производительности, но зато крайне специализированной.

Именно такой, по мемуарам создателей. Э стал из-за сочетания нескольких подходов. В первую очередь, архитектура Э отличалась уникально низкими потерями на распараллеливание при многопроцессорности. Т. е. производительность при добавлении процессоров росла почти линейно. Но цена - стековость и ЯВУ как язык низкого уровня. Потом, мыслилось резко упростить создание ПО. И в третьих - обойти ограничения элементной базы.

[SiMor]

Ну, значит, не было тогда (в 80-е) нормального САПР. Нормального в нынешнем понимании.

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

И вообще рассматриваемая мини-эвм будет очень востребована в НИИ и КБ, если поставлять ее с периферией, предустановленным ПО и обучением пользователей, а также сразу разводить по комнатам подразделения терминалы и связать сию станцию с ВЦ организации, машины которого все больше будут выполнять роль сначала файл-серверов, затем серверов приложений и прочая.

Так что какой там нафиг обсчет моделей? Кусочками, и только кусочками.

Ну, у нас же в реале считали, причем на ЕС1022.

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

Изменено 15 Sep 2011 пользователем SiMor

[Вандал]

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

Какого именно оборудования?

И вообще рассматриваемая мини-эвм будет очень востребована в НИИ и КБ, если поставлять ее с периферией, предустановленным ПО и обучением пользователей, а также сразу разводить по комнатам подразделения терминалы и связать сию станцию с ВЦ организации, машины которого все больше будут выполнять роль сначала файл-серверов, затем серверов приложений и прочая.

1. С какой периферией?

2. С каким предустановленным ПО, откуда его взять?

3. В школьное время ходил в кружок, где нас знакомили с ЭВМ. Нас там учили не работе с компьютером, а рассказывали об архитектуре ЭВМ, алгоритмах и их основных элементах, а еще учили читать записанное на перфокартах (наверное, это было необходимо тогдашним пользователям? Ведь даже машинки, которые печатают на тех же перфокартах записанное на них, предоставлялись в порядке очереди). Впрочем, как-то раз мне дали даже перфокарты набивать. То же самое повторилось на занятиях в УПК, где у нас была специальность типа оператора ЭВМ. А все действительно нужное для работы мы, уже в институте, постигали самообразованием, в основном, чтением хелпов.

4. Чтобы машина выполняла роль файл-сервера, необходимо множество согласованных форматов. Когда бишь это в США появилось и в результате чего? Серверы приложений по тому времени - лишняя сущность. Реалии 90-х в 80-е смотрятся смешно. Парадигма поменялась. Впрочем, и неудивительно, если ЛВС в 80-е давала пропускную способность мегабит (хорошо если 10 мегабит).

[Вандал]

Ну, у нас же в реале считали, причем на ЕС1022.

Зависит от задачи. Количество и тип конечных элементов (2-D, 3-D) какие?

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

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

[SiMor]

Какого именно оборудования?

Технологического. Без подробностей.

1. С какой периферией?

Терминалы, ЦПУ, дигитайзер, плоттер, НЖМД, модем минимум.

2. С каким предустановленным ПО, откуда его взять?

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

3. В школьное время ходил в кружок, где нас знакомили с ЭВМ. Нас там учили не работе с компьютером, а рассказывали об архитектуре ЭВМ, алгоритмах и их основных элементах, а еще учили читать записанное на перфокартах (наверное, это было необходимо тогдашним пользователям?

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

Ведь даже машинки, которые печатают на тех же перфокартах записанное на них, предоставлялись в порядке очереди).

Это говорит о плохом планировании работы ВЦ, и больее ни о чем.

Впрочем, как-то раз мне дали даже перфокарты набивать. То же самое повторилось на занятиях в УПК, где у нас была специальность типа оператора ЭВМ. А все действительно нужное для работы мы, уже в институте, постигали самообразованием, в основном, чтением хелпов.

Не знаю, в институте нам раз показали, как работать на Наири, потом уже там сам ходил, записывался, перфокарт там набивать было не надо. Машина должна быть проста в пользовании и иметь необходимый софт.

4. Чтобы машина выполняла роль файл-сервера, необходимо множество согласованных форматов. Когда бишь это в США появилось и в результате чего? Серверы приложений по тому времени - лишняя сущность. Реалии 90-х в 80-е смотрятся смешно.

Смешно, не смешно, а компьютерные сети в СССР с 1960 года...

Кстати, вот тут

http://www.fid.ru/museum/hall1/12/exponat13/

статья Клесова из "Науки в СССР", 6, 1985 г.

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

Ну и где смешно-то будет за реалии 90-х в 80-е?

Изменено 15 Sep 2011 пользователем SiMor

[Вандал]

Технологического. Без подробностей.

Ну а если без подробностей, то резцы и сверла рассчитывать - это одно, штампы для крупных изделий - это другое, а термическую закалку для опять же крупной заготовки - это совсем третье. Важно необходимое количество конечных элементов, а также тип модели (2-D или 3-D).

Терминалы, ЦПУ, дигитайзер, плоттер, НЖМД, модем минимум.

Терминалы тоже разные бывают. "Консул" пойдет? До конца 70-х многих удовлетворял. Ну а если с дигитайзером, как насчет Tektronix 4014? Боюсь, до конца 70-х ни на что лучшее все равно рассчитывать было нельзя.

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

Какие задачи? В 1978 году в тех же Штатах кое-кого вполне устраивал UNIX BSD 1.0. Тоже типа, установили, после чего погнали задачи. У каждого свои. А насчет разработать - извините, но поставщики железа не могут работать по принципу чего изволите.

Взять тот же ANSYS. По нынешним меркам так себе пакет, вещь в себе. Однако, Джон Свонсон прежде, чем его разработать, 6 лет работал на Вестингауз, где набирался практического опыта. затем он ушел на вольные хлеба, но при этом оставался консультантом в Вестингауз по расчетам, и имел закрепленную договором возможность набирать данные, которые мог использовать для верификации расчетов своей математики. И только к концу 70-х у него что-то коммерчески более-менее удачное начало получаться. Да, команда у него была небольшая на тот момент.

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

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

Это говорит о плохом планировании работы ВЦ, и больее ни о чем.

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

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

Название такое слышал. Но не встречал. в реальной работе все больше ЕС видел. И перфокарты там, увы, основной метод ввода программ были. Впрочем, если откомпилированные, то могли и на перфоленте хранить. Это все уровень 70-х и начала 80-х.

Машина должна быть проста в пользовании и иметь необходимый софт.

Понимаете ли, пока не появились нормальные терминалы, кто мог представить, что может быть что-то лучше консула? Тот, кто не видел VT340, был счастлив работать на Tektronix 4014. Ну а Tektronix серии 42хх даже и по нынешним временам неплох для конструкторов. Мышка разве что неудобная. Ну Вы, должно быть, в курсе, какие тогда мышки были. Или вот появились у нас графстанции на базе 286-х, автокад запускать. 19-дюймовый экран со специальным адаптером (кроме автокада, ничто больше его не понимало), второй экран монохромный с графическим адаптером Геркулес (все команды отображались на нем, освобождая основной экран), плюс планшет (дигитайзер) в двумя вариантами указателя - мышеподоный и перо. Народ был доволен, несмотря на скромные характеристики машины и малый объем диска. Им даже такого хватало. И, главное, кроме них, на эти станции никто не претендовал.

То же самое и с необходимым софтом. Пока не попробуешь вкусненького, как понять, что тот софт, который есть - фуфло? Сравнивать-то не с чем.

Смешно, не смешно, а компьютерные сети в СССР с 1960 года...

Для кого-то и 300 бод - сеть. Кену Томпсону в свое время хватило для дистанционной отладки по крэш-дампу.

Кстати, вот тут

http://www.fid.ru/museum/hall1/12/exponat13/

статья Клесова из "Науки в СССР", 6, 1985 г.

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

Ну и где смешно-то будет за реалии 90-х в 80-е?

email - это в Юниксе рубеж 70-х и 80-х. Первые BBS с возможностью обмена сообщениями появились чуть позже. При чем тут 90-е?

[SiMor]

Ну а если без подробностей, то резцы и сверла рассчитывать - это одно, штампы для крупных изделий - это другое, а термическую закалку для опять же крупной заготовки - это совсем третье. Важно необходимое количество конечных элементов, а также тип модели (2-D или 3-D).

Вы отождествляете собственно САПР/АСТПП и МКЭ, как один из методов моделирования.

Сегодняшняя проблема как раз в том, что МКЭ стали пихать во все дырки и решать все проблемы брутфорсом, что уводит в сторону от системного понимания проблем проектирования и создает вот эту самую иллюзию, что для САПР якобы всегда нужны супер-пупер системные ресурсы. А главное в САПР не моделирование, а классификация образов, которая применительно к задачам САПР совершенно не автоматизирована.

Т.е. и сегодня имеем лишь автоматизацию отдельных задач при проектировании, как и в 70-х. До полноценной САПР далеко, как до Луны.

Терминалы тоже разные бывают. "Консул" пойдет? До конца 70-х многих удовлетворял. Ну а если с дигитайзером, как насчет Tektronix 4014? Боюсь, до конца 70-х ни на что лучшее все равно рассчитывать было нельзя.

В 1978 году уже можно рассчитывать на VT100. Это же все-таки миди-ЭВМ вырисовывается.

Какие задачи?

Задачи АСУП, САПР, АСТПП, АСНИ.

В 1978 году в тех же Штатах кое-кого вполне устраивал UNIX BSD 1.0. Тоже типа, установили, после чего погнали задачи. У каждого свои.

Да они не "у каждого свои", а типовые. Даже обыкновенный ПМК требует прикладного ПО, что HP в 70-х почему-то прекрасно понимал.

Взять тот же ANSYS. По нынешним меркам так себе пакет, вещь в себе. Однако, Джон Свонсон прежде, чем его разработать, 6 лет работал на Вестингауз, где набирался практического опыта. затем он ушел на вольные хлеба, но при этом оставался консультантом в Вестингауз по расчетам, и имел закрепленную договором возможность набирать данные, которые мог использовать для верификации расчетов своей математики. И только к концу 70-х у него что-то коммерчески более-менее удачное начало получаться. Да, команда у него была небольшая на тот момент.

Ну это он методом тыка набирался.

Но еще использование АВМ привело к вопросу, что нужны специализированные фирмы, которые разрабатывают программные решения. в которых есть постановщики, которые и есть те самые носители опыта, есть связь с потребителями, и т.д. и т.п. Просто эта шумиха вокруг ЭЦВМ ("Во! АВМ прошлый век! У нас новые подходы!") привели к тому, что снова вернулись к кустарщине.

Не было.

Это в каком году появилось?

Нет, это говорит о дефицитности ресурсов.

Нет, это говорит именно о плохом планировании, потому что ресурсы проедали на заказах простаивающих из-за некомплексности информатизации машин.

Кстати, перфокарты были тоже дефицитом, так как требовали очень дорогого картона.

Финские - да, наших было как грязи.

Название такое слышал. Но не встречал. в реальной работе все больше ЕС видел. И перфокарты там, увы, основной метод ввода программ были. Впрочем, если откомпилированные, то могли и на перфоленте хранить. Это все уровень 70-х и начала 80-х.

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

Уровень 70-х - это уже магнитные ленты и дисплеи. Перфокарты использовались с Минском, а на ЕС-ках все это обычно жило из-за плохо развитой периферии, если ВЦ-шники, замкнутые в себе, старались заказать машину покрупнее и сэкономить на периферии.

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

IBM 2260 канает для развития воображения любителей Консула?

Ну Вы, должно быть, в курсе, какие тогда мышки были.

Прямоугольные.

То же самое и с необходимым софтом. Пока не попробуешь вкусненького, как понять, что тот софт, который есть - фуфло? Сравнивать-то не с чем.

Не сравнивать надо, а задачи ставить.

Для кого-то и 300 бод - сеть. Кену Томпсону в свое время хватило для дистанционной отладки по крэш-дампу.

Потом скажут "для кого-то и гигабит-сеть". И что?

email - это в Юниксе рубеж 70-х и 80-х. Первые BBS с возможностью обмена сообщениями появились чуть позже. При чем тут 90-е?

При том, что реализована ФУНКЦИЯ общения по компьютерным сетям.

[Вандал]

Вы отождествляете собственно САПР/АСТПП и МКЭ, как один из методов моделирования.

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

Сегодняшняя проблема как раз в том, что МКЭ стали пихать во все дырки и решать все проблемы брутфорсом, что уводит в сторону от системного понимания проблем проектирования и создает вот эту самую иллюзию, что для САПР якобы всегда нужны супер-пупер системные ресурсы. А главное в САПР не моделирование, а классификация образов, которая применительно к задачам САПР совершенно не автоматизирована.

Я думаю, что и не будет автоматизирована. Представьте себе идеальный случай. Создали систему, которая сама, на основе анализа образов, принимает решения, что и как обсчитывать. Замечательно? Но остается вопрос: кто будет нести ответственность за результат? В любом случае - это люди. Но согласятся ли люди тупо ставить свою подпись под решениями, которые принимает компьютер? Я думаю, что не согласятся, потому что это не тупой обсчет, пусть и методом грубой силы. А коль так, то зачем этот модуль системе, если человек все равно будет дублировать. По этой же причине и экспертные системы не пошли, и никогда не пойдут.

И еще: практика - критерий истины. Уход в сторону брутфорса был оправдан тем, что вычислительные ресурсы росли (и продолжают расти) опережающими темпами по отношению к требованиям.

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

Т.е. и сегодня имеем лишь автоматизацию отдельных задач при проектировании, как и в 70-х. До полноценной САПР далеко, как до Луны.

А больше ничего и не нужно.

В 1978 году уже можно рассчитывать на VT100. Это же все-таки миди-ЭВМ вырисовывается.

Можно. Только он не графический.

Задачи АСУП, САПР, АСТПП, АСНИ.

Так, чтоб не запутаться.

АСУП - автоматизированные системы управления предприятием.

САПР - системы автоматизированного проектирования

АСТПП - автоматизированные системы технологической подготовки производства

АСНИ - автоматизированные системы научных исследований.

Не имею ничего против частного решения этих задач даже на ЕС-1022. Частного, понимаете? То есть, в Вашем конкретном случае. Но Вы же требуете централизованных усилий по разработке таких систем, создания специальных учреждений. А Вы понимаете, что чем выше степень обобщения, тем выше (зависимость, скорее всего, описывается логистической кривой, или чем-то вроде этого) затраты на разработку, и тем более требовательным к железу становится софт. Потому что в нем поневоле будут включены не только нужные конкретно Вам участки кода, но и "паразиты", без которых, тем не менее, софт работать не будет. Тут, как говорится, интересы разработчиков вступают в конфликт с интересами Заказчика. Разработчикам мало написать, чтоб работало: им написанное потом еще сопровождать надо. А значит, они будут пытаться написать код, максимально унифицированный (поддержка различных версий - это кошмар, хуже которого трудно себе что-то представить).

Ну и: успешные реализации САПР и АСТПП я видел. АСУП - ха-ха-ха. Байки про то, как внедряется SAP/R3, знаете? АСНИ - вот честно говоря, вообще не представляю универсальных решений. Одно дело - адронный коллайдер, и совсем другое - исследования ваших любимых подвесок.

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

Да они не "у каждого свои", а типовые. Даже обыкновенный ПМК требует прикладного ПО, что HP в 70-х почему-то прекрасно понимал.

Именно, что разные. Смотрите сами: если инженерный калькулятор имеет стандартный набор операций и функций, то для ПМК уже нужна толстая книжка программ, которые можно только вручную вколачивать, в противном случае никаких сменных модулей памяти не напасешься. Персоналка может очень сильно отличаться по набору установленного на ней ПО, в зависимости от задач пользователя. Ставить все подряд - только засорять реестр. То есть, с усложнением систем, увеличвается и количество вариаций в конфигурации.

Ну это он методом тыка набирался.

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

Но еще использование АВМ привело к вопросу, что нужны специализированные фирмы, которые разрабатывают программные решения. в которых есть постановщики, которые и есть те самые носители опыта, есть связь с потребителями, и т.д. и т.п. Просто эта шумиха вокруг ЭЦВМ ("Во! АВМ прошлый век! У нас новые подходы!") привели к тому, что снова вернулись к кустарщине.

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

Это в каком году появилось?

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

Нет, это говорит именно о плохом планировании, потому что ресурсы проедали на заказах простаивающих из-за некомплексности информатизации машин.

Похоже, Вы пребываете в опасной иллюзии, что все можно заранее предусмотреть и заранее спланировать? Вы - детерминист? Если да, то что Вы делаете на ФАИ?

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

Младшие серии и модели вряд ли потянут. На старших так и делали. Но. Другой режим - это другая ОС. О чем я и говорю, что нельзя все загонять в ГОСТ.

Уровень 70-х - это уже магнитные ленты и дисплеи. Перфокарты использовались с Минском, а на ЕС-ках все это обычно жило из-за плохо развитой периферии, если ВЦ-шники, замкнутые в себе, старались заказать машину покрупнее и сэкономить на периферии.

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

IBM 2260 канает для развития воображения любителей Консула?

1) Дорог он в сравнении с консулом.

2) Прототип - легко. А вот повторить не только дешевый, но и с приемлимой надежностью - вот в чем проблема. Консулы часто системной консолью работали, так сказать последний аргумент систадмина.

3) На конец 70-х можно найти что и получше. Тот же Tektronix 4014 или VT100.

4) САПР на алфавитно-цифровых дисплеях - это как? Для САПР даже такая роскошь (в СССР 70-х) как цвет, крайне настоятельная потребность.

Прямоугольные.

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

Не сравнивать надо, а задачи ставить.

Побывал Стив Джобс в Пало Альто, впечатлился их идеями, и поставил задачу своим разработчикам, сделать так же. Так родился GUI для Макинтоша. Подсмотрел - и получил. Другой вариант - сам Пало-Альто. Собрали хиппанов-энтузиастов и дали резвиться. С подсмотреть в СССР проблема. Получается только с опозданием в несколько лет. С созданием коллективов а-ля PARC - тоже. У нас плановая экономика, кто же позволит хиппям волосатым государственные деньги проедать за красивые слова? Задергают их проверками,они и разбегутся, прежде чем выдадут на гора хоть что-то полезное. Других же способов изобретать что-то новое, не знаю.

Потом скажут "для кого-то и гигабит-сеть". И что?

То, что надо понимать, что от какой производительности можно требовать. На 300 бод Вы даже синхронизации надежной не построите, что важно, например, для распределенных вычислений. И соединение по ФИДО, по протоколу MNP5 Вам, при такой скорости, боюсь, не светит.

При том, что реализована ФУНКЦИЯ общения по компьютерным сетям.

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

[SiMor]

Вполне возможно, что есть и другие методы. Но если нужны прочностные расчеты, то что еще можно использовать для моделирования?

Вообще-то мы говорим о САПР, а компьютеризация МКЭ - это не САПР, это опять же точечная компьютеризация, и это еще уровень 70-х. В 70-х у нас МКЭ гоняли.

Я думаю, что и не будет автоматизирована. Представьте себе идеальный случай. Создали систему, которая сама, на основе анализа образов, принимает решения, что и как обсчитывать. Замечательно? Но остается вопрос: кто будет нести ответственность за результат? В любом случае - это люди. Но согласятся ли люди тупо ставить свою подпись под решениями, которые принимает компьютер? Я думаю, что не согласятся, потому что это не тупой обсчет, пусть и методом грубой силы.

Коллега, такое впечатление, что мы с Вами дискутируем в 1958 году.

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

И еще: практика - критерий истины. Уход в сторону брутфорса был оправдан тем, что вычислительные ресурсы росли (и продолжают расти) опережающими темпами по отношению к требованиям

.

На самом деле они значительно отстают от требований, если рассматривать задачу создания полнофункциональных САПР.

В целом, складывается впечатление, что Вы видите вытеснение человека из процесса проектирования.

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

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

Уже нашли.

А больше ничего и не нужно.

Если проектируете старье, которое не обойдет конкурентов.

На сегодняшний день есть необходимость в САПР, которая автоматизирует не только технологическое (70-е гг) и предметное (90-е гг) конструирование, но и функциональное.

Можно. Только он не графический.

Выдает массив данных, если надо, вывод в графической форме на более мощной машине.

Не имею ничего против частного решения этих задач даже на ЕС-1022. Частного, понимаете? То есть, в Вашем конкретном случае. Но Вы же требуете централизованных усилий по разработке таких систем, создания специальных учреждений. А Вы понимаете, что чем выше степень обобщения, тем выше (зависимость, скорее всего, описывается логистической кривой, или чем-то вроде этого) затраты на разработку, и тем более требовательным к железу становится софт.

Боже мой, сколько теории, и все в полном отрыве от практики!

Что, на каждом предприятии с Союзе были разные системы бухучета? Разные системы конструкторской документации? Да даже если взять АСНИ, что БПФ в разных конторах разный, что ли? Смешно.

Ну и: успешные реализации САПР и АСТПП я видел. АСУП - ха-ха-ха. Байки про то, как внедряется SAP/R3, знаете?

Я даже знаю их причину: новый российский (и не только) менеджмент, который научился "спрашивать с людей", но патологичсеки не способен УПРАВЛЯТЬ чем-либо, включая иконки на собственном десктопе.

АСНИ - вот честно говоря, вообще не представляю универсальных решений.

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

[SiMor]

Именно, что разные. Смотрите сами: если инженерный калькулятор имеет стандартный набор операций и функций, то для ПМК уже нужна толстая книжка программ, которые можно только вручную вколачивать, в противном случае никаких сменных модулей памяти не напасешься. Персоналка может очень сильно отличаться по набору установленного на ней ПО, в зависимости от задач пользователя. Ставить все подряд - только засорять реестр. То есть, с усложнением систем, увеличвается и количество вариаций в конфигурации.

А юзать приставку "Нота" для ввода программ религия не позволяет? Как и держать библиотекит программ на бобинах?

Я имею в виду настольные ПМК 70-х, а не "наладонники", которыми обкормили Союз.

Даже у Электроники Д3-28 был ввод с кассеты.

А иначе не получится. Передний край потому что.

Ну у нас-то получалось. Передний край - нормальное место для конструктора.

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

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

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

Use the Force. (с)

Давайте не будем говорить о временах, в которые ни Вы, ни я еще не жили.

Ну я-то жил, так что буду говорить.

Вплоть до 90-х с разработкой ПО справлялись одиночки и небольшие коллективы, человек в 10 максимум.

Вы смешиваете группу разработчиков и фирму-производитель софта.

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

Во-первых, не у нас.

Во-первых, на той же элементной базе, что была у нас.

Во-вторых, как бы эта бандура помогла научиться работать с тем же IBM?

Через сменные носители, на которые выводились массивы данных.

На практике такая штука в 70-х в исследованиях и проектировании снимала где-то 3/4 случаев необходимости записываться на машину. несмотря на все ее несовершенство.

Похоже, Вы пребываете в опасной иллюзии, что все можно заранее предусмотреть и заранее спланировать?

Похоже, Вы единственный в СССР 70-х, кто не заметил эту проблему и не говорил о ней? Кроме Леонида Ильича, у него другие проблемы.

Младшие серии и модели вряд ли потянут. На старших так и делали. Но. Другой режим - это другая ОС. О чем я и говорю, что нельзя все загонять в ГОСТ.

Загоните в отраслевой стандарт, его проще менять. Вопрос административной техники.

А Вы скидку на качество наших магнитных лент сделайте.

Не жаловались.

Перфокарты - надежнее.

А вот на них жаловались.

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

Себе? Для домашнего ПК? Для домашнего бытовой магнитофон подойдет и лента тип 10.

Для работы 12,7 мм было хоть залейся...

А хранить у себя пачку перофкарт или перфоленту - никаких проблем.

Они в гастрономе не продаются. Откуда их брать? с ВЦ? А магнитную ленту в таком случае оттуда же брать религия не позволяет?

1) Дорог он в сравнении с консулом. <br>2) Прототип - легко. А вот повторить не только дешевый, но и с приемлимой надежностью - вот в чем проблема. Консулы часто системной консолью работали, так сказать последний аргумент систадмина.<br>3) На конец 70-х можно найти что и получше. Тот же Tektronix 4014 или VT100.<br>4) САПР на алфавитно-цифровых дисплеях - это как? Для САПР даже такая роскошь (в СССР 70-х) как цвет, крайне настоятельная потребность.

1. Дорог не терминал, а низкая отдача от ВЦ из-за отсталой периферии.

2. Дали бы на наш завод - даже лучше бы сделали.

3. Вот это бы и сделали.

4. Она вначале даже без дисплеев была.

Да, а еще они шариковые, так что точность оставляла желать много лучшего.

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

Побывал Стив Джобс в Пало Альто, впечатлился их идеями, и поставил задачу своим разработчикам, сделать так же. Так родился GUI для Макинтоша. Подсмотрел - и получил. Другой вариант - сам Пало-Альто. Собрали хиппанов-энтузиастов и дали резвиться. С подсмотреть в СССР проблема. Получается только с опозданием в несколько лет. С созданием коллективов а-ля PARC - тоже. У нас плановая экономика, кто же позволит хиппям волосатым государственные деньги проедать за красивые слова? Задергают их проверками,они и разбегутся, прежде чем выдадут на гора хоть что-то полезное. Других же способов изобретать что-то новое, не знаю.

Ссылку на Альтшуллера дать?

То, что надо понимать, что от какой производительности можно требовать. На 300 бод Вы даже синхронизации надежной не построите, что важно, например, для распределенных вычислений. И соединение по ФИДО, по протоколу MNP5 Вам, при такой скорости, боюсь, не светит.

Для задач конца 70-х - более чем отлично. Безбумажную передачу документов обеспечит. Кстати, "Экспресс" уже работал. а это еще тот уровень технологий.

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

Ну опять общие фразы вместо возражений?

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

Изменено 19 Sep 2011 пользователем SiMor

[Вандал]

Вообще-то мы говорим о САПР, а компьютеризация МКЭ - это не САПР, это опять же точечная компьютеризация, и это еще уровень 70-х. В 70-х у нас МКЭ гоняли.

Не надо подменять термины. CAE - это тоже САПР, его составляющая. У нас была реализована связка ANVIL/ANSYS. Чертили, затем передавали модель расчетчикам, те считали. Геморроя было много, но, в конце концов, стало получаться. В той же CATIA есть модули для всех этапов проектирования и внедрения в производство. И это не единственная система сейчас.

Коллега, такое впечатление, что мы с Вами дискутируем в 1958 году.

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

Если я принимаю решения, зачем мне компьютер, который

.

На самом деле они значительно отстают от требований, если рассматривать задачу создания полнофункциональных САПР.

Смотрите опыт "Сухого" по проектированию Суперджета методами САПР, с минимумом испытаний. Точно так же спроектирован и Boeing 787 Dreamliner. Есть уже давно нормальные полнофункциональные САПР. Но для этого в 90-е годы нужны были графстанции уровня IBM RS/6000 или SGI. Сейчас уже и Интел-платформа тянет.

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

Не получится. Ибо конструктор уже привык заниматься рутинной работой. Переучивать его получается в 1 случае из 10. Надо готовить людей с нуля. Но готовить с нуля можно только под готовую систему. Замкнутый круг получается.

Уже нашли.

Что нашли? Ручной контроль?

Если проектируете старье, которое не обойдет конкурентов.

На сегодняшний день есть необходимость в САПР, которая автоматизирует не только технологическое (70-е гг) и предметное (90-е гг) конструирование, но и функциональное.

Это фантастика. Про Альтшуллера и его методы потом.

Выдает массив данных, если надо, вывод в графической форме на более мощной машине.

А ввод? Тоже в графической форме с более мощной машины?

Боже мой, сколько теории, и все в полном отрыве от практики!

Самокритично.

Что, на каждом предприятии с Союзе были разные системы бухучета? Разные системы конструкторской документации? Да даже если взять АСНИ, что БПФ в разных конторах разный, что ли? Смешно.

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

Я даже знаю их причину: новый российский (и не только) менеджмент, который научился "спрашивать с людей", но патологичсеки не способен УПРАВЛЯТЬ чем-либо, включая иконки на собственном десктопе.

Нет. Во-первых, все эти байки - лишь повторение аналогичных баек с Запада. Там тоже никуда не годный менеджмент?

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

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

[Вандал]

А юзать приставку "Нота" для ввода программ религия не позволяет? Как и держать библиотекит программ на бобинах?

Не религия, а отсутствие интерфейсов.

Я имею в виду настольные ПМК 70-х, а не "наладонники", которыми обкормили Союз.

Даже у Электроники Д3-28 был ввод с кассеты.

Представьте себе: ни разу не видел. А на "наладонники" не надо лить грязи. Наши Б3-34 и МК54 нас не раз спасали в условиях стабильно зависавших компьютеров ВЦ. И лабы на них делали по МКЭ, и курсовики считали. Так что правильно ими Союз обкормили.

Ну у нас-то получалось. Передний край - нормальное место для конструктора.

Абсолютизация своего успешного опыта - верный путь к фейлу. Я Вам указал на главную причину Вашего успеха - Вы решали частную задачу. Это всегда намного проще. Знаете, в начале 90-х хакры баловались программками "полета", которые на 286-м процессоре и простейшей видеокарте показывали полет над офигительно сложным рельефом. Вот только применявшиеся ими алгоритмы были абсолютно немасштабируемыми, и ни на что, кроме демок, не годились. Скольким предприятиям из других отраслей Вам удалось свой опыт успешно передать?

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

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

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

Это не только в Союзе. Творческий поиск не совместим с бизнесом, так как в бизнесе важна предсказуемость, то есть сроки.

Ну я-то жил, так что буду говорить.

И сколько Вам лет тогда было?

Вы смешиваете группу разработчиков и фирму-производитель софта.

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

Я ничего не смешиваю. Это Вы меня ошибочно понимаете.

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

Во-первых, на той же элементной базе, что была у нас.

Через сменные носители, на которые выводились массивы данных.

Простите, но указанный Вами калькулятор вкупе с бобинами никак не решит проблему обучения пользователей интерактивной работе на микроБЭСМ с ОС на базе ЮНИКС и Диспак (не представляю, как скрестить ужа с ежом, но раз автор написал, значит он-то это как-то представляет, судя по всему, он в теме ОС ДИСПАК рубит больше меня).

Похоже, Вы единственный в СССР 70-х, кто не заметил эту проблему и не говорил о ней? Кроме Леонида Ильича, у него другие проблемы.

В 70-е я еще маленький был.

1. Дорог не терминал, а низкая отдача от ВЦ из-за отсталой периферии.

2. Дали бы на наш завод - даже лучше бы сделали.

3. Вот это бы и сделали.

4. Она вначале даже без дисплеев была.

По пунктам 1 и 4 Вы сами себе противоречите. Насчет пункта 2 - таки Вы чем занимались: машинами и локомотивами или электроникой?

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

Сколько стоила шариковая мышь 90-х, и сколько стоит та оптическая мышь, с которой Вы сравниваете? Я с удовольствием перешел на оптику. Единственная проблема - дешевым мышкам специальные коврики нужны, типа клетчатые. Дорогие работают на любой поверхности с великолепной точностью.

Ссылку на Альтшуллера дать?

По поводу Альтшуллера и веры в исключительную и универсальную эффективность какой-либо методики отсылаю Вас к "Мифическому человеко-месяцу". Ребята в Пало-Альто без всякого Альтшуллера справились. А вот идеи Альтшуллера так и не получили всеобщего признания, значит, было в них что-то не то. Мое мнение - это шаманство, НЛП для инженеров. Хотя, конечно, из каждого концепта можно почерпнуть что-то полезное, пусть даже если это и "никогда так не делайте". Я знаю одно: серебряной пули не существует. Отсюда, человек, который пытается мне продать серебряную пулю - или мошенник, или неадекватен.

Для задач конца 70-х - более чем отлично. Безбумажную передачу документов обеспечит. Кстати, "Экспресс" уже работал. а это еще тот уровень технологий.

Оффлайн - да. Синхронизация задач счета - нет. Файловые серверы и серверы приложений - тоже нет.

Ну опять общие фразы вместо возражений?

Учусь у Вас. А Вы ищете непременно возражений, а дополнения не принимаются? Это что, у Альтшуллера так принято?

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

Собственно, подтверждение принципа об адекватности ресурсов задачам. Поэтому исходя из ресурсов можно оценить, какого уровня задачи ставились. Что вы постоянно и подтверждаете. Спасибо за блестящее раскрытие темы о том, как работали в 70-е, и что можно ждать от микроБЭСМ. А то тут некоторые, похоже, вообразили, что микроБЭСМ станет полным аналогом графстанций 90-х, только на 10 лет раньше, со всеми вытекающими отсюда плюшками. Надеюсь, Ваш правдивый рассказ остудит эти горячие головы.

[SiMor]

Не надо подменять термины. CAE - это тоже САПР, его составляющая.

Так САПР или составляющая?

Не надо подменять термины.

Если я принимаю решения, зачем мне компьютер

Да Вам все равно, девочки-деталировщицы у Вас или компьютер. Что быстрее делает, то и будет.

Смотрите опыт "Сухого" по проектированию Суперджета методами САПР, с минимумом испытаний.

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

Не получится. Ибо конструктор уже привык заниматься рутинной работой. Переучивать его получается в 1 случае из 10. Надо готовить людей с нуля. Но готовить с нуля можно только под готовую систему. Замкнутый круг получается.

Да все получится. Кто хочет - подтянется, кто не хочет, того заменят компьютером. То же самое, что произошло с чертежниками и машинистками.

Что нашли?

Как проектировать без ошибок.

Это фантастика.

Поздравьте, мы фантастику сделали былью.

А ввод? Тоже в графической форме с более мощной машины?

Не обязательно.

Например, исходные координаты для МКЭ вполне было достаточно вогнать с текстового терминала, это на три-четыре порядка меньший объем данных, чем на выводе.

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

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

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

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

Восхищен высотой уровня, но все равно неверно.

Во-первых, все эти байки - лишь повторение аналогичных баек с Запада. Там тоже никуда не годный менеджмент?

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

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

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

[SiMor]

Не религия, а отсутствие интерфейсов.

Да запишите между прогами на ленте голоосвые сообщения и буде Вам интерфейс.

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

Представьте себе: ни разу не видел. А на "наладонники" не надо лить грязи. Наши Б3-34 и МК54 нас не раз спасали в условиях стабильно зависавших компьютеров ВЦ. И лабы на них делали по МКЭ, и курсовики считали. Так что правильно ими Союз обкормили.

Ну, я тоже юзал и МК-56, и МК-61, в основном по тем же причинам, по которым фотографируют мобильником, то-есть везде таскать с собой можно. Но по сравнению с Д3-28 это - жалкое подобие. Единственно, что по этим игрушкам навыпускали много литературы, потому проще было осваивать.

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

Не угадали.

Скольким предприятиям из других отраслей Вам удалось свой опыт успешно передать?

А зачем? Что бы мы с этого тогда имели?

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

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

Это не только в Союзе. Творческий поиск не совместим с бизнесом, так как в бизнесе важна предсказуемость, то есть сроки.

Если Вы шаурмой торгуете - да.

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

И сколько Вам лет тогда было?

Достаточно, чтобы работать на этих АВМ.

Я ничего не смешиваю. Это Вы меня ошибочно понимаете.

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

А Вы в курсе, что с Билли озолотилась вся его команда?

Не вся, а только основатели.

Так что не самый худший вариант. И тут мы подходим к тому, что в СССР не было возможностей ни для развития софтовых фирм, ни для фирм, занимающихся обучением. Невозможен Майкрософт в СССР. Что возможно - так это НИИ, которые будут прожирать ресурсы.

Вы плохо представляете себе современные фирмы разработки софта.

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

Простите, но указанный Вами калькулятор вкупе с бобинами никак не решит проблему обучения пользователей интерактивной работе на микроБЭСМ с ОС на базе ЮНИКС и Диспак (не представляю, как скрестить ужа с ежом, но раз автор написал, значит он-то это как-то представляет, судя по всему, он в теме ОС ДИСПАК рубит больше меня).

А каклькулятор вообще не для решения этой проблемы, а для разгрузки микроБЭСМ от мелочовки.

В 70-е я еще маленький был.

А я в 70-е уже за компом сидел.

По пунктам 1 и 4 Вы сами себе противоречите.

Вы путаете проблемы обеспечения периферией с проблемами создания периферии.

Насчет пункта 2 - таки Вы чем занимались: машинами и локомотивами или электроникой?

И тем и этим, и еще другим. И еще информатизацией того и этого и другого.

Сколько стоила шариковая мышь 90-х, и сколько стоит та оптическая мышь, с которой Вы сравниваете?

А разницу в серийности выпуска и изменения степени интеграции комплектующих Вы учли?

Технологически это устройства одного ценового порядка. Платы, пластмассовое литье.

По поводу Альтшуллера и веры в исключительную и универсальную эффективность какой-либо методики отсылаю Вас к "Мифическому человеко-месяцу". Ребята в Пало-Альто без всякого Альтшуллера справились. А вот идеи Альтшуллера так и не получили всеобщего признания, значит, было в них что-то не то. Мое мнение - это шаманство, НЛП для инженеров.

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

Хороший хирург поможет плохому танцору.

Я знаю одно: серебряной пули не существует.

Коллега, Вы бы лучше Карлхайнца Рота изучали, чем Ван Хельсинга

Оффлайн - да. Синхронизация задач счета - нет. Файловые серверы и серверы приложений - тоже нет.

Нескромный вопрос: как Вы себе представляете функционал файлового сервера?

Собственно, подтверждение принципа об адекватности ресурсов задачам. Поэтому исходя из ресурсов можно оценить, какого уровня задачи ставились. Что вы постоянно и подтверждаете. Спасибо за блестящее раскрытие темы о том, как работали в 70-е, и что можно ждать от микроБЭСМ. А то тут некоторые, похоже, вообразили, что микроБЭСМ станет полным аналогом графстанций 90-х, только на 10 лет раньше, со всеми вытекающими отсюда плюшками. Надеюсь, Ваш правдивый рассказ остудит эти горячие головы.

А в конце 70-х и не надо полного аналога графстанций 90-х.

Нужна миди-ЭВМ, которая устанавливается в подразделении и берет на себя 90% задач, которые по объему вычислений выше уровня ПМК, что разгружает ВЦ организации и открывает путь к превращению последнего в датацентр.

[Вандал]

Так САПР или составляющая?

Не надо подменять термины.

Никто и не подменяет. Кто хочет понять, тот понимает, кто хочет "дискутировать" - придирается к словам. ANSYS - это САПР, нацеленная на тепловые и прочностные расчеты. Исходные данные (геометрию) можно хоть массивом данных вводить, хоть на графическом терминале рисовать, хоть из другой САПР (конструкторской) импортировать через всякие интерфейсные форматы. Если же брать более широко, когда мы рисуем конструкцию, делаем модель, потом ее же обсчитываем, потом ее же используем в технологической подготовке производства, то это уже не САПР, а сквозное проектирование. В первом случае системы, во втором процесс. Процесс может быть реализован как взаимноувязанными системами, так и единой системой, составленной из модулей, отвечающих за ту или иную задачу. Поэтому на западе обычно и говорят не САПР, а CAD/CAM System или CAD/CAE/CAM System. Если Вы привыкли к другой классификации - это Ваше право, но не делайте вид, что Ваша классификация единственно возможная и самая правильная.

Да Вам все равно, девочки-деталировщицы у Вас или компьютер. Что быстрее делает, то и будет.

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

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

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

Да все получится. Кто хочет - подтянется, кто не хочет, того заменят компьютером. То же самое, что произошло с чертежниками и машинистками.

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

Как проектировать без ошибок.

Это возможно только в устоявшихся отраслях. Вы к ним отношения не имеете.

Поздравьте, мы фантастику сделали былью.

Только в Вашем частном случае. В это верю.

Не обязательно.

Например, исходные координаты для МКЭ вполне было достаточно вогнать с текстового терминала, это на три-четыре порядка меньший объем данных, чем на выводе.

Представьте себе, так и вводил. Но это МКЭ, Вы же сами говорите, что МКЭ - это еще не весь САПР. А вот как автокадить или анвилить?

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

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

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

А вот теперь ответьте мне: в чем принципиальная разница между "конфигурированием" 1-С, написанием и переписыванием хранимых процедур в Парусе и написанием софта на C# с опорой на СУБД и готовые библиотеки на .NET? А еще раньше вместо всего этого были пользовательские библиотеки с реализациями оконного интерфейса, и работы с файлами dBase/Foxpro/Paradox. Ну а еще раньше были SQL на мэйн-фреймах и КОБОЛ. Программистской работы все равно много, плюс есть нюансы с нестандартным оборудованием (это для АСНИ).

Восхищен высотой уровня, но все равно неверно.

Обоснуйте.

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

Или просто Вы чего-то не понимаете. Мир убежал вперед, а Вы мыслите категориями своего времени. Тоже возможно. Мир меняется, а Вы ригидны.

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

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

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

2. Типовой ряд ПО под все задачи выльется в такой винегрет, который сам по себе неизбежно будет порождать ошибки. Создание матрицы, учитывающей все возможные варианты комбинаций параметров, и её заполнение, потребуют времени, превосзодящего время жизни системы, создаваемой на основе их. Это верно для 70-х, 80-х и, отчасти, 90-х. Сейчас, слава богу, winintel-платформа уже 15 лет жива и еще лет на десять её хватит. Но и здесь есть нюансы.

3. Про инцидент с ракетой Ариан слышали? Сейчас начинают поговаривать про контрактное программирование. Однако, однако... Нет поддержки со стороны языков (кроме Ады), непонятно, чем это обернется при переходе от 32- к 64-битным системам и далее, и т.д. и т.п. Передний край, опять на ощупь, опять с ошибками, никуда не деться.

[SiMor]

Никто и не подменяет. Кто хочет понять, тот понимает, кто хочет "дискутировать" - придирается к словам. ANSYS - это САПР, нацеленная на тепловые и прочностные расчеты.

Да ясно, что такое ANSYS.

Разница между нашими поколениями в том, что вас учили ударяться в рассуждения, а нас - рещать задачу.

Еще раз возвращаю к сути вопроса: мини-БЭСМ была бы востребована для задач САПР. То, что в то время был автоматизирован технологический уровень конструирования, сейчас - предметный, уже детали.

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

А что, возможен какой-то другой вариант? С механоцентрическими воззрениями давно покончено.

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

Коллега, прежде чем произносить слово "интерполяция", сначала посмотрите его значение в словаре.

А пока социализм не кончился, с ними ничего и не происходило.

Значит, у нас социализма не было, потому что чертежницы исчезли

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

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

Это возможно только в устоявшихся отраслях.

Кто Вам сказал эту глупость?

Только в Вашем частном случае.

Коллега, а может быть, не надо считать наличие ума частным случаем, а невежество - общим? Хочется как-то верить в человечество

Представьте себе, так и вводил. Но это МКЭ, Вы же сами говорите, что МКЭ - это еще не весь САПР. А вот как автокадить или анвилить?

Под автокадом Вы подразумеваете систему создания графической документации? Ну, при быстродействии тех машин девочка быстрее нарисует.

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

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

А вот теперь ответьте мне: в чем принципиальная разница между "конфигурированием" 1-С, написанием и переписыванием хранимых процедур в Парусе и написанием софта на C# с опорой на СУБД и готовые библиотеки на .NET?

В трудоемкости.

А еще раньше вместо всего этого были пользовательские библиотеки с реализациями оконного интерфейса, и работы с файлами dBase/Foxpro/Paradox. Ну а еще раньше были SQL на мэйн-фреймах и КОБОЛ.

А еще раньше был Фортран и все равно необходимости создания типовых программ это не отменяет.

Обоснуйте.

Вы опередили мое обоснование своей "интерполяцией"

Или просто Вы чего-то не понимаете. Мир убежал вперед, а Вы мыслите категориями своего времени. Тоже возможно. Мир меняется, а Вы ригидны.

Тогда я постою - пусть мир меня догонит

1. Пока типовой ряд ПО разработают - на местах лапу сосать?

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

А когда оно появится, то окажется, что то, что на местах сами сделали, идеологически не стыкуется с предлагаемым стандартом.

С какой стати? Не надо считать в 7-=х всех идиотами.

Собственно, 90-е и показали всю эту историю.

А здесь можно.

Есть и хорошая сторона - программистам всегда работа найдется. Впрочем, Вы, похоже, предлагаете армию клонов, программистов мыслящих одинаково, и уже на местах работающих по стандартам, которые только-только разрабатываются, чтобы минимизировать затраты на последующую миграцию.<br>2. Типовой ряд ПО под все задачи выльется в такой винегрет, который сам по себе неизбежно будет порождать ошибки. Создание матрицы, учитывающей все возможные варианты комбинаций параметров, и её заполнение, потребуют времени, превосзодящего время жизни системы, создаваемой на основе их.

Я повторяю: Вас учили ударяться в рассуждения, нас - решать задачи.

Все это нормально делали, и не надо лузеровскую философию разводить.

3. Про инцидент с ракетой Ариан слышали?

А Вы про инцидент с Першингами слышали?

Если конкуренты делают все через одно место, не пытайтесь повторить.

[Вандал]

Да запишите между прогами на ленте голоосвые сообщения и буде Вам интерфейс.

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

Чиво-чиво?

Цитата

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

Не угадали.

Цитата

Скольким предприятиям из других отраслей Вам удалось свой опыт успешно передать?

А зачем? Что бы мы с этого тогда имели?

Вопросов более не имею. Взаимоисключающие параграфы рулят.

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

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

Если Вы шаурмой торгуете - да.

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

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

(1)

Достаточно, чтобы работать на этих АВМ.

(2)

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

В сторону: жалобу модератору о переходе на личности, что ли, отправить?

Не вся, а только основатели.

Так это и есть команда.

Вы плохо представляете себе современные фирмы разработки софта.

Я достаточно хорошо представляю себе западные конторы. Делать работника акционером - там весьма распространенная практика. По крайней мере, в 90-е так было. Но мы куда-то уклонились от темы.

Вы путаете проблемы обеспечения периферией с проблемами создания периферии.

Да нет, это Вы опять не желаете понимать. В общем, замнем для ясности.

И тем и этим, и еще другим. И еще информатизацией того и этого и другого.

Ну-ну. Человек, не работающий в какой-то сфере более трех лет, утрачивает компетентность в этой области. Это факт. Теперь мне понятно, кто вы, а также степень Вашей компетентности. Спасибо за разъяснения.

А разницу в серийности выпуска и изменения степени интеграции комплектующих Вы учли?

Технологически это устройства одного ценового порядка. Платы, пластмассовое литье.

Комплектующие бывают разные. Это и на цене отражается. Кстати, Вы имеете в виду проводные оптические мышки, надеюсь?

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

"Нам пофиг, у нас НЛП работает, это с Вами что-то не так" - стандартный ответ энелперов их критикам. Нет валидизации, нет и научных рекомендаций к применению. То есть шаманство. Спасибо за наглядное подтверждение моего тезиса "ТРИЗ - это НЛП для инженеров".

Хороший хирург поможет плохому танцору.

А широкополая шляпа поможет защититься от лапши, которую вешают на уши.

Коллега, Вы бы лучше Карлхайнца Рота изучали, чем Ван Хельсинга

Вы таки хотите нам продать серебряную пулю?

Нескромный вопрос: как Вы себе представляете функционал файлового сервера?

Нескромный встречный вопрос: Вы что, не читали базовых книжек по проектированию или обзору операционных систем? Сие забавно. В 70-е уже все идеи, которые сейчас поддерживаются в файл-серверах, были. Как же Вы занимались автоматизацией, не имея даже базовых знаний в области computer science?

А в конце 70-х и не надо полного аналога графстанций 90-х.

Опять взаимно противоречивые параграфы. Таки мощность достаточна или недостаточна? Между прочим, в данном параграфе я с Вами согласен. Если бы Вы не придирались к словам, а внимательно прочитали то, что я написал ранее, Вы бы увидели, что именно это я и говорил: в 70-е стомипсовые графстанции не нужны.

Нужна миди-ЭВМ, которая устанавливается в подразделении и берет на себя 90% задач, которые по объему вычислений выше уровня ПМК, что разгружает ВЦ организации и открывает путь к превращению последнего в датацентр.

Низводить мэйнфрейм до уровня датацентра? Я уж молчу о том, откуда такая идея могла взяться в 70-е.

[Вандал]

Да ясно, что такое ANSYS.

Еще раз возвращаю к сути вопроса: мини-БЭСМ была бы востребована для задач САПР. То, что в то время был автоматизирован технологический уровень конструирования, сейчас - предметный, уже детали.

Собственно, по этому вопросу консенсус. Именно это я и объяснял более юным коллегам. По остальным вопросам будете разбираться с местным модератором.

[SiMor]

Чиво-чиво?

Того.

Что Вам мешает использовать магнитную ленту? Имен файлов не видно? Голосовые сообщения пишите.

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

Еще раз, постарайтесь слушать внимательно.

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

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

Опять пошло общефразие.

Так это и есть команда.

И какое это отношение имеет к возможности создания в СССР фирм производства софта?

Королев что, за большое бабло работал?

Ну-ну. Человек, не работающий в какой-то сфере более трех лет, утрачивает компетентность в этой области. .

Это не помешало моему изделию получить награду ВДНХ.

Так что, коллега, не читайте переводных учебников менеджмента.

Комплектующие бывают разные. Это и на цене отражается.

Глубокая мысль. Именно поэтому с течением времени (и степени интеграции) мыши дешевеют, а не потому что качество мышей 90-х супер-пупер.

"Нам пофиг, у нас НЛП работает, это с Вами что-то не так" - стандартный ответ энелперов их критикам. Нет валидизации, нет и научных рекомендаций к применению. То есть шаманство. Спасибо за наглядное подтверждение моего тезиса "ТРИЗ - это НЛП для инженеров".

Спасибо за наглядное подтверждение басни Крылова "Мартышка и очки"

Вы таки хотите нам продать серебряную пулю?

Вы таки хотите спровоцировать личную перепалку?

Нескромный встречный вопрос: Вы что, не читали базовых книжек по проектированию или обзору операционных систем?

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

Опять взаимно противоречивые параграфы. Таки мощность достаточна или недостаточна?

И достаточна и недостаточна.

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

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

Не факт.

Низводить мэйнфрейм до уровня датацентра?

А кто предлагает низводить? Нужно и то и другое.

[SiMor]

Собственно, по этому вопросу консенсус. Именно это я и объяснял более юным коллегам. По остальным вопросам будете разбираться с местным модератором.

Только говоря об Альтшуллере, не забывайте перечитывть "Мартышку и очки". :)

[Вандал]

Того.

Что Вам мешает использовать магнитную ленту? Имен файлов не видно? Голосовые сообщения пишите.

Зачем мне использовать магнитную ленту сейчас?

Еще раз, постарайтесь слушать внимательно.

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

А теперь Вы постарайтесь слушать внимательно.

1) Из того, что количество ошибок с приобретением опыта уменьшается, вовсе не следует, что ошибок не будет вообще.

2) "Успешный конструктор" становится таким, потому что получает опыт. "Успешный" в кавычках, потому что от "успешного" до "лузера" - один шаг.

3) Любая НИР - это не свободный поиск, а решение определенной цели. А "чтобы задать верный вопрос, надо знать большую часть ответа".

И хватит об этом.

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

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

[Вандал]

И какое это отношение имеет к возможности создания в СССР фирм производства софта?

Королев что, за большое бабло работал?

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

[SiMor]

Зачем мне использовать магнитную ленту сейчас?

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

1) Из того, что количество ошибок с приобретением опыта уменьшается, вовсе не следует, что ошибок не будет вообще.

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

2) "Успешный конструктор" становится таким, потому что получает опыт. "Успешный" в кавычках, потому что от "успешного" до "лузера" - один шаг.

Не-а

Успешный конструктор - именно тот, который заранее выявляет свое недомыслие и устраняет его.

3) Любая НИР - это не свободный поиск, а решение определенной цели. А "чтобы задать верный вопрос, надо знать большую часть ответа".

"Решение определенной цели"...

Коллега, а Вы русский язык где изучали?

А меня интересует, как Вы это себе представляете.

То-есть, Вы так и не ответили.

Кстати, мануал Новелл Нетвари тут ни при чем, это не учебник по проектированию и устройству ОС.

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

Вот так по мануалам, по мануалам...

Изменено 19 Sep 2011 пользователем SiMor

[SiMor]

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

Лаврентьев же предложил, что Сталин сразу приказал ИТМВТ создать.

Так что информатизация - это изначально интересы обороны.

[dragon.nur]

Marlagram

И вначале графика должна быть 768(либо хотя бы 384)х288 и потом ... х576. У нас другой стандарт ТВ, и моники будут другими.