Педалирование "еврейской темы", как бы намекает на личность и в целом персонаж для меня вполне понятный и знакомый - в эмиграции таких "пикейных жилетов" предостаточно.
А он эмигрант?... Вы прям заинтриговали, надо почитать, пока только одну статью прочитал. Но судя по тому, что он так быстро метнул такую кучу статей, он их написал заранее и единомоментно просто опубликовал.
Цитатаalex654 ()
Как раз нет. Довольно ограниченный словарный запас, причем весьма специфический. Например, автор явно неравнодушен к прилагательному "чудовищн/ый/ая". Пафосный тон временами перетекающий в историку, рваное повествование. Какой-то графоман на пенсии.
Я вас теперь боюсь. Прежде чем писать сюда статью, трижды подумаю!
К сожалению, мастерское владение языком и большой словарный запас даны не каждому. Хотелось бы читать только хорошие тексты, но приходится читать то, что есть. Не опровергая всю возможную критику, просто хочу отметить, что мне, например, некоторые сообщенные автором факты были интересны, я их не знал, особенно про "до 360-ю" эпоху. Хотя вот то, что он где-то подвирает, это, конечно, плохо. Но он же не специально, я думаю, он, может, и сам верит в то, что пишет (это ничего не меняет по сути, но все же)! И вообще, может, у него дома красивый котик!
ЦитатаShigure ()
В группе любителей БЭСМ-6 автора этих статей тоже раскритиковали вплоть до желания писать статью опровержениеВопрос по теме, а разве S/360 давала виртуализацию, как пишет автор? А то из его статьи может показаться, что запустили IBM овцы S/360 в 1964 году и сразу в ней была виртуальная память до 4 гб и все прочие поздние прелести...
Да, я тоже вот это про виртуализацию видел, бред, конечно. Конечно, на первых редакциях 360 не было никакой виртуальной памяти! И тем более, никакая операционка ее бы не поддержала. В ранних 90х встречались даже совсем дремучие ворованные версии PSP и MFT, там выставлялись явный размер железной памяти, и эти системы сохранились потому, что в них работали 1-2 задачи, которых никто не трогал. Но ведь автор вроде бы не инженер, а журналист, нет? Для инженера пишет бойко, для журналиста - слишком много технических подробностей. Загадочное дело!
Выйду на пенсию - тоже буду малограмотные статьи писать. Обязательно со словом "чудовищно"! Отличное хобби же.
Выйду на пенсию - тоже буду малограмотные статьи писать
В малограмотных статьях недостатка нет. Вот с грамотными не так чтобы густо. Я например хотел бы почитать статью про философию архитектуры z. Потому что я тут начал разбираться в свободное время, и, честно говоря, мой энтузиазм сильно поубавился. Потому что я не понимаю, зачем все делать так сложно в наши дни? Я все таки не с вин/юникс пришел, а с i, и там все делается ну качественно проще. Батчи нужны - есть они и замечательно можно тюнить. Интерактивные - пожалуйста. Писать интерфейсы в 5250? Да вообще никаких проблем. И, главное, все как-то последовательно сделано, все под рукой. Не надо лезть в ассемблер (да его и нет по сути, MI - это другое), чтобы делать топовые бизнес приложения и выжимать все из архитектуры. А тут какой-то зоопарк различных технологий, языков и систем и везде все со своими заморочками... Да еще и ассемблер предполагается к регулярному использованию потому что без него в ряде случаем никак (насколько я понимаю). Программирование каналов вот... Я не понял, это реально сегодня надо этим заниматься при разработке приложений? Нет, я понимаю, что наверное, можно. Но блин, как и кто это будет потом поддерживать? Это надо держать в команде человека, который только этим и будет заниматься. Вообщем, не могу разобрать, где анахронизм, а где мощная идея и как надо разрабатывать современные приложения для z чтобы именно использовать преимущества архитектуры. Например, в i философия определяется тем, что это изначально capability based system. Понимая одну эту суть, дальше становятся логичным и понятным почему и зачем сделано так в системе. А про z я вот не понимаю :-(.
Сообщение отредактировал alex654 - Вт, 26.04.2022, 13:42
В малограмотных статьях недостатка нет. Вот с грамотными не так чтобы густо.
Ну их же не специально пишут малограмотно))) Изначально же все хотят хорошо написать, а получается так, как получается.
Цитатаalex654 ()
Я например хотел бы почитать статью про философию архитектуры z.
Цитатаalex654 ()
Потому что я не понимаю, зачем все делать так сложно в наши дни?
Никто не делает архитектуру Z в наши дни. И нет никакой единой философии. Есть много-много разных концепций, костылей и прочего. Хотя нет, вру. Есть философия - это поддержка унаследованного всего. Не дай бог что-то тронуть! Что в 60-е протиснулось в систему - то и будет сидеть вечно. Дальше будут появляться костыли, чтобы и старое как-то осталось, и что-то новое пропихнуть, хотя далеко не всегда понятно, кому это новое нужно и кто на нем будет ездить (типа этого гребанного докера, USS при наличии Линукса и гипервизоров и проч). Поэтому то, что мы называем сейчас "архитектурой Z", представляет из себя дикое нагромождение идей и подходов за все без малого 60 лет развития, слепленное в одну кучу костылями. И над всем этим одна главная мысль: что раньше у уважаемых заказчиков в этом ящике работало, должно продолжать работать дальше! Поэтому и выходит вот это -
Цитатаalex654 ()
А тут какой-то зоопарк различных технологий, языков и систем и везде все со своими заморочками...
Так что да, так и есть. Как Саграда Фамилия, но еще и облеплена киосками а-ля Черкизон. VM более логичен, но и его прилично загадили из-за странных политических решений и невменяемой маркетинговой политики за все эти годы.
Цитатаalex654 ()
Да еще и ассемблер предполагается к регулярному использованию потому что без него в ряде случаем никак (насколько я понимаю). Программирование каналов вот...
А это фигня. С какой это стати? Ассемблер нужен, если хочется понимать глубоко архитектуру и быть действительно системным инженером, а не системным администратором. Как и программирование работы ввода-вывода. Я немного поделал таких программ в молодости, на прямых SIO и на DIAG, и больше нужда не приводила. Но если хочется разбираться глубоко - то да, ассемблер не помешает. Хотя бы для того, чтобы Принципы работы понять. Но я знаю хороших системных администраторов, которые занимаются своими кусками работы в ОС и никогда ни строчки на ассемблере не писали и не видели. И разработчики уже давно не пишут на ассемблере ввод-вывод! У нас вообще для мейнфрейма пишут на высокоуровневых языках уже лет 40. Где-то парасистемные вещи могут быть на ассемблере, но это скорее экзотика или специальные нужды.
Цитатаalex654 ()
Вообщем, не могу разобрать, где анахронизм, а где мощная идея
Анахронизм вполне может быть мощной идеей сам по себе. Ибо развитие идет по спирали, и централизованный мейнфрейм вполне может стать супер-пупер идеей. А если серьезно, то тут клубок идей разной давности, и каждая из идей может стать, по оценочному суждению, то анахронизмом, то банальностью, то интеллектуальным прорывом.
Цитатаalex654 ()
как надо разрабатывать современные приложения для z чтобы именно использовать преимущества архитектуры.
Прежде, чем разрабатывать, надо ж проектировать. И, увы, для новых проектов мейнфрейм - это очень спорное решение, хотя не исключаю, что, как архитектура с высокой пропускной способностью ввода-вывода, он где-то будет вне конкуренции. Если такое место найдете - то дальше или в IBM, или в Software AG, или к другому какому производителю ПО на платформе, они расскажут, как программировать с использованием их софта. Где-то будет Ява, где-то Natural, где-то еще чего. Нет общих рекомендаций. И имейте в виду вендор-лок. Это сейчас, как никогда, актуально.
а вот это, IMHO очень спорно. Я давно хотел бы увидеть объективное сравнение USS и z/Linux на каких-то синтетичских тестах и на конкретных приложениеях. Меня смущает вот что: z/Linux - это портированный Linux c довольно примитивными драйверами дисков ECKD, а USS во-первых, не просто тупо портированный, а все же несколько переосмысленный код, и, во-вторых, USS использует ввод-вывод z/OS. Поэтому я смею предположить, что приложение в USS будет работать лучше, чем в z/Linux, и хотелось бы знать так ли это в самом деле, и если да, то насколько именно лучше
Цитата
Да еще и ассемблер предполагается к регулярному использованию потому что без него в ряде случаем никак (насколько я понимаю).
конечно же нет, и IBM уже давно не пишет на ассемблере даже то, что пишется на ассемблере - есть PL/S, есть Metal С). А для прикладного программирования вообще никаких проблем - пишите на java, PHP, Perl, C/C++ если PL/1, COBOL, REXX не нравится). Я же уже где-то тут писал - подключитесь к z/OS с помощью putty по ssh или telnet, и работайте, как в обычном Unix, и можете даже не подозревать о существовании традиционного интерфейса 3270 и всяких там TSO/ISPF...
Цитата
Как Саграда Фамилия, но еще и облеплена киосками а-ля Черкизон.
+100500. отличное описание z/OS. и все это сооружение построено на платформе с колесами, гусеницами, винтами и реактивными двигателями. (zSeries).
Сообщение отредактировал Gregory - Вт, 26.04.2022, 19:55
...работайте, как в обычном Unix, и можете даже не подозревать о...
И зачем тогда z? Речь ведь не о том, в каких тулах мне удобнее работать (у меня нет проблем с XEDIT и терминалом). А о том, как использовать в решениях преимущества архитектуры и какие они вообще эти преимущества.
z/Linux - это портированный Linux c довольно примитивными драйверами дисков ECKD
Именно так. Поэтому НЕ НАДО Линукс на мейнфрейме использовать с ECKD, надо использовать его с родным для него (и для физических дисков) блочным доступом. Тогда все намного быстрее и приличнее. А вообще, тема USS-zLinux - это дико интересная история. С одной стороны, USS - это во многом zOS, крепко интегрированная в систему вещь, и это хорошо. Но это все-таки ограниченное количество поддерживаемых библиотек и API. Коллеги пытались туда ради эксперимента некую программку из BSD, вроде как очень стандартизированную, так вот чтобы запустить в USS пришлось попотеть. Но запустили. Да, туда много чего портировали, но много меньше, чем есть в Линуксе. А с другой стороны, в Линукс программка влетела запросто, без усилий, и там много чего есть, готового. Зато работает хуже, и надо для приличной работы запускать под VM и на FBA. В общем, свои плюсы и минусы. Как мне сказал один товарищ, словак, который был техническим директором по Линуксу в IBM по Восточной Европе, "да, ситуация неоднозначная, поэтому как скажут, на такой вывод заказчика выведем". Удобно, чо.
А о том, как использовать в решениях преимущества архитектуры и какие они вообще эти преимущества.
Их, преимуществ, может не быть, увы. С учетом внешних обстоятельств мейнфрейм вообще может быть токсичной темой. А может и не быть.
Технически любые решения можно сделать практически на любой базе. У мейнфрейма есть технические особенности - как, например, высокая пропускная способность железного ящика по вводу-выводу - но это может не определять, по совокупности, его преимущество, потому что он может проседать в другой области.
Вот пишут что успех 360 обусловлен решением IBM применить микрокод, который позволяет писать код не зависящий от конкретной "железной" реализации. Это в свою очередь обеспечило возможность бинарной переносимости софта, чего не позволяло большинство тогдашний платформ.
Вот пишут что успех 360 обусловлен решением IBM применить микрокод, который позволяет писать код не зависящий от конкретной "железной" реализации. Это в свою очередь обеспечило возможность бинарной переносимости софта, чего не позволяло большинство тогдашний платформ.
Этим сейчас уже никого не удивишь. Это уже давно не преимущество.
Ну, там вроде история еще и в том, что в отличие от железа, микрокод рассматривался как имплементация API (ISA). А по какому-то тогдашнему судебному решению, воспроизведение API не требовало лицензирования. И т.о. другие компании могли легально выпускать машины на той же ISA или продукты (компиляторы, например) которые генерировали код под 360/370. Сам, микрокод же считался частью железа и естественно проприетарным. Это сделало архитектуру привлекательно для разработчиков. Хотя, сейчас, наверное, вендор лок полный.
И т.о. другие компании могли легально выпускать машины на той же ISA или продукты (компиляторы, например) которые генерировали код под 360/370.
Ну так так и было. До какого-то момента. Сейчас с z архитектурой работает только IBM, и попытки выпустить эмуляторы или еще чего похожее жестко блокируются во всем мире. Правда, теперь у нас это можно делать, но уже никому не нужно - дешевых железок навалом, вкладываться в создание альтернативной платформы, совместимой с z/390 - бессмысленно. Вообще я вижу для внутрироссийских лавок один путь - замораживание того софта, что есть, запуск его на б/у железках, пока возможно и максимальные усилия на реинжениринг на другие платформы, на любые, какие можно себе позволить, и постепенный уход на эмуляторы. Потом все.
Без адекватной поддержки производителем любая система мертва. Поддержка унаследованной системы, главная концепция которой - длинная жизнь за счет сохранения инвестиций, возможна, в среднем, на более длительное время, чем динамичной остромодной быстро меняющейся платформы, но это тоже не вечный и не самодостаточный процесс.
IBM, придавливая независимых производителей совместимых программных (напоминаю - даже в свободном Линуксе есть драйверы, например, OSA, которые без исходников, и никто никогда без них не обойдется, ибо это сетевые адаптеры) и аппаратных платформ (как они тупо Геркусес не задавили - загадка, но вот ADCD, например, залочили на ZPDT, а раньше этого не было), с одной стороны, вроде как гарантировал себе доход, с другой стороны - оставил дойную корову без размножения, делая ей инъекции долгой жизни тем, что некоторую модернизацию ведет и подтягивает всякие модные слова, учит где-то как-то молодежь.. Но все будет вертеться не вокруг расширения рынка, а вокруг его замораживания и замыкания на себя, любимых.
Цербер выпустили, да. Это набор программ, частично доработанных, и его выпустили много-много (сильно больше 15) лет назад с активным привлечением производителей - IBM и Software AG. В те годы ситуация была сильно другая, было много планов и амбиций, она даже от ситуации 2010х отличалась кардинально. Цербер - результат попытки занести VM и Adabas на объекты с особыми требованиями. Туда в это время заносили и железо импортное без особых проблем. И производители софта думали, вместе с российскими партнерами, что за счет таких систем, как Цербер, они расширят сферу применения своих продуктов (немножко), но зато надолго закрепятся в закрытом контуре. Считаю, что и тогда вероятность такого была минимальна, такой подход опоздал безнадежно.
Если бы не содействие (и это еще мягко сказано!) фирм-производителей, не было бы никакого Цербера, я же открытым текстом это тут написал. Даже тогда это была уникальная и авантюрная история, штучная. Сейчас, в нынешних условиях, никакой Цербер или что-то подобное, да и вообще масштабный вменяемый проект с использованием мейнфреймов и современного ПО, невозможен.
Кстати, вместе с Цербером был еще Каскад, средство разработки прикладных программ на базе Natural, которое дополняло Цербер. В сообщении на сайте упоминается - http://s390soft.ru/blog/2020-01-06-64 - и тоже абсолютно невозможная сейчас вещь. Оно уже тогда было поздно, решение опоздало на годы.
А сейчас то взаимодействие кажется удивительным и прекрасным, которое уже никогда не повторится.
И, повторю еще раз, не только политическая обстановка изменилась - позиция самой IBM изменилась. Это теперь не техническая фирма, а консалтинговая. Основной фокус - модные слова. Поэтому и попались на том, что врали в отчетности и завышали прибыльность модных направлений.
В общем, никому не интересно мейнфреймы РАЗВИВАТЬ. Интересно тянуть их как можно дольше в том виде, как есть. И если для этого нужно немножко их подпилить - подпилят, деваться некуда. Но это всегда будут а) догоняющие действия (как Цербер и Каскад), б) вынужденные и неловкие.
А как это дело лицензировалось? Т.е. с каждой поставкой Цербера в IBM шли какие-то роялти или что-то подобное? Или может быть полноценная лицензия от IBM требовалась клиентам? Или может IBM передал исходный код VM/ESA и НИЦЭВТ теперь может им распоряжаться как пожелает?
