IT в России и мире в реалиях мирового кризиса

Цитата: adolfus от 12.11.2024 22:35:05Литограф  ASML -- это всего лишь инструмент. Очень сложный, но все таки инструмент. Тут все ясно -- нет инструмента, нет и изделия. Но, ASML свои литорафы может продать куда угодно кроме TMSC. Если не сегодня, то завтра. И что этому инструменту подсунут в виде фотошаблонов, то он в кремнии и выдаст. А вот сделать фотошаблоны. чтобы выхлоп литографа  ASML функционировал как задумано, это уже и есть та самая технология. Вот ее TMSC и закокомил.

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

Цитата: Vaal от 13.11.2024 11:24:53А фотошаблоны, - это оснастка для литографа. Значительно менее сложная, чем литограф.
Ежели недокитайцы пожелают закрыть фотошаблоны, ASML вполне может закрыть литографы для них. Эта история только начинается, короче.

Что начит "закрыть"?
 
Это их собственная внутренняя "фишка", они её, в отличии от продукции ASML не экспортировали. И "на сторону" не продавали.
 
Т.е. необходимое, чтобы на входе изображение которое должно получиться после травления экспонированной пластины превратить на выходе в маску для фотошаблона с учётом дифракции. Решение обратной задачи с нелинейными формами. Со всеми необходимыми для рассчёта совсем не слабыми вычислительными мощностями.
 
И плюс всё то, о чём написал Senya выше:

Цитата: Senya от 13.11.2024 11:31:23А дальше идут десятки (сейчас может уже и сотни, я от жизни отстал) таких операций как ионная имплантация всевозможными легандами, окисление, напыление, травление ионное и химическое, и отжиги, отжиги, отжиги для восстановления кристаллической структуры после каждого чиха, и всё это с точностью до вольт, градусов и секунд, чтобы в процессе не уничтожить уже созданные на кристалле структуры. Что собственно и есть технология (а всё предыдущее - производственная оснастка). Ну и библиотеки элементов, где все пространственные структуры на кристалле спроектированы так, чтобы их можно было с помощью данной технологии изготовить. Сложное это дело.

 
Причём даже при размещении завода в США... они по-прежнему все рассчёты могут делать у себя на Тайване. Файл со слоем туда, файл с экспозицией фоторезиста для изготовления шаблона обратно.

Цитата: adolfus от 13.11.2024 09:43:43Фотошаблон производится из файла с описанием топологии изделия.
Степпер берет шаблон, оптически его уменьшает и "тиражирует" по пластине, сдвигая ее на определенный шаг и засвечивая. Это один из компонент того "сарая", что производит ASML.
И тут вопрос -- каким образом излучение УФ лазера с длиной волны ~100 нм, проходя через маску, создает на кристалле картинку с разрешением несколько нм. Дело в том, что реально на кристалле после прохождения маски из-за диффракции на всей маске создается определенная интерференционная картинка. Т.е. вся маска вносит вклад в каждую точку результирующей засветки, которая представляете собой интерференционную картинку. И создание фотошаблона -- это создание таких масок, проходя через которую картинка на кристалле будет представлять собой требуемую топологию. Достаточно сложная вычислительная задача и не только лишь все... TMSC из тех, кто умеет и ASML к этому никакого отношения.

Какой нах УФ лазер 100нм?
Передовые сканеры работают уже на рентгеновсом излучении. Рентгеновскую оптику, кстати, для ASML русские разработали... а делают немцы, если не ошибаюсь. Там длина волны порядка 10 нм.

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

Цитата: Pnb от 13.11.2024 09:12:06У нас пользовались в интерфейсах только чисто виртуальными функциями. Тогда в структуре первым элементом идет адрес таблицы с адресами функций. Конечно все равно могут быть разночтения типа 32\64 или соглашения о вызове функций. Во всяком случае так можно было взаимодействовать между борландом и микрософтом.

Вызывать методы класса из борланда в майкросорт
Вы очень смелые люди. Уважаю

Цитата: ivrom от 08.11.2024 20:39:51Большинство считают С++ слишком сложным в первую очередь для понимания. Это непонимание, как писать на нём просто и безопасно. А раз так, то похоже он будет вытеснен в область системного программирования [только]. И мир продолжит экстенсивный путь развития в виде увеличения размера памяти и количества ядер процессора для покрытия издержек "непонимания". Так тоже делать можно. Только это печально. Да здравствует Питон!

   
Если для программиста С++ оказался "сложным", то такой программист способен писать только какие-то диалог-боксы для какой-то одноразовой примитивной системы...
Это какой-то индийский погромист...

Цитата: ivrom от 08.11.2024 20:39:51Большинство считают С++ слишком сложным в первую очередь для понимания. Это непонимание, как писать на нём просто и безопасно.

Безопасность в С++ достигается полным отказом от наследования, полиморфизма и прочего зла, типа создания шаблонов, котороыми никто кроме меня не будет пользоваться.
Также, если вы не пишете oбработчики исключений, позволяющие исправить ситуацию, вызвашую исключение, и продолжать выполнение программы, то нет необходимости использовать try-catch.
И самая мякотка -- повторное использование классов. Когда я начинал программировать на С++, мои классы изобиловали не нужными на тот момент вещами -- я верил, когда-нибудь это может понадобиться. Спустя какое-то время выяснилось, что ничего из того, что было "про запас" написано, так и не сыграло. При этом классы в разных проектах, выросшие из таких "избыточных", постоянно дорабатывались под конкретную задачу и в результате между ними осталось мало общего. Сегодня я вообще не думаю насчет того, что разрабатываемый класс может понадобиться в каком-нибудь другом проекте -- я в это не верю. Время, потраченное на проектирование "прозапас" и прочую шлифовку -- это просто просранное время.

Цитата: adolfus от 14.11.2024 01:01:33Безопасность в С++ достигается полным отказом от наследования, полиморфизма и прочего зла, типа создания шаблонов, котороыми никто кроме меня не будет пользоваться.

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

Цитата: adolfus от 14.11.2024 01:01:33
Также, если вы не пишете oбработчики исключений, позволяющие исправить ситуацию, вызвашую исключение, и продолжать выполнение программы, то нет необходимости использовать try-catch.
И самая мякотка -- повторное использование классов. Когда я начинал программировать на С++, мои классы изобиловали не нужными на тот момент вещами -- я верил, когда-нибудь это может понадобиться. Спустя какое-то время выяснилось, что ничего из того, что было "про запас" написано, так и не сыграло. При этом классы в разных проектах, выросшие из таких "избыточных", постоянно дорабатывались под конкретную задачу и в результате между ними осталось мало общего. Сегодня я вообще не думаю насчет того, что разрабатываемый класс может понадобиться в каком-нибудь другом проекте -- я в это не верю. Время, потраченное на проектирование "прозапас" и прочую шлифовку -- это просто просранное время.

Все эти претензии могут быть высказаны к любому объектно ориентированному языку. Ничего С++ специфического здесь не озвучено.

Давайте пойдём от обратного. Рассмотрим, кто и на чём программирует. По большому счёту, языки делятся на транслируемые (компилируемые) и интерпретируемые. Есть множество ресурсов с указанием некоего рейтинга (по использованию?) языков программирования. На вершине находятся сплошь интерпретируемые языки, такие как Python, JavaScript (в обоих ипостасях - как клиентский язык и как Node.js), Java, PHP. Наличие jit опустим - он может наличествовать в любом интерпретируемом языке. Всё это массовый сегмент для большинства программистов, имеющий низкий порог вхождения с точки зрения образования и опыта.

С другой стороны, в наличии языки программирования для написания высокопроизводительных (как правило серверных) приложений и ОС, GUI. И в этом сегменте наличествует С, С++. Есть некоторое количество golang(самое известное - Docker, зачем писали на go - не знаю). Rust и странно-для-чего-деланный C# (для Windows, про Mono помнить можно, но лучше забыть) в некоторых количествах присутствует.

Итак, вам нужно написать высокопроизводительное сетевое приложение/демон. Каков будет ваш выбор? Интерпретируемые языки отпадут сразу и по производительности и по потребляемым ресурсам. Не боясь особо ошибиться, это будет C. С++ воспоследует. Если для демона важны расширения посредством разделяемых библиотек - то это 99% будет С. Иначе - возможны варианты. Но стоит заметить, что именно относительно свежие дополнения С++ в виде поддержки асинхронных алгоритмом + корутины сделает процесс написания максимально безболезненным и быстрым. И что самое важное - логика программы будет прямой, почти как в отсутствие конкурентной среды и с блокируемыми системными вызовами. И исключения будут работать и обрабатываться правильно.

А вот в языках, где event loop  работает с событиями (через futures/queues + обработчик события, например в виде .then{...}) логика рваная и инвертированная. В такой среде исключения не работают правильно. Скажем, libevent и Node.js именно так и построен. Вы озвучили проблемы с исключениями в С++ в такой среде, но именно для С++ и асинхронных алгоритмов с корутинами это ни разу не проблема.

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

А где требования пониже и/или ресурсы (программистские) пожиже - там и Python с Node.js свою нишу найдёт.

PS Существуют книги/учебники из цикла "XXX за YYY дней". Применительно к С++ это "С++ за 21 день". Я его ради любопытства лет 20 назад поглядел. Так это вполне себе был учебник, чтобы за месяц начать что-то писать на С++. Так что и для новичков С++ не имеет запредельной сложности для вхождения.

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

Цитата: ivrom от 14.11.2024 02:51:56Безопасность С++ в первую очередь достигается тем, что это строго типизированный язык. Даже С с ним и рядом не стоял. А вот гибкость, наложенную поверх ограничивающей строгой типизации, и обеспечивают шаблоны.

Си такой же типизированный язык, как и С++. Просто у них разный уровень возможностей, поэтому кажется, что второй "более строго типизирован". Оба поддерживают "implicit & explixit conversions", которые полносью определяют степень строгости типизации. Строго типизированный язык не имеет "implicit conversions". Также к строгости прямое отношение имееттакой "сахарок", как автоматический вывод типа. В этой части С более строго типизирован, нежели С++. Например, автоматический вывод типа в С отсутствует, там где С++ это имеет. Строго типизированный язык не имеет нечего похожего на "reinterpret cast", котороый  сводит С++ к отсутствии строгой типизации.

Цитата: ivrom от 14.11.2024 02:51:56PPS Утверждаю, что основные претензии к С++ базируются на очень старых версиях языка (или на вовсе нестандартном Microsoft VS), по крайней мере не позже С++98. С каждым новым стандартом С++ становится проще для использования.
...
Количество используемого и необходимого для запоминания материала может даже уменьшится.

Смотря что понимать под словом "проще" и в каком окружении это "проще" реализуется. Ссылки, например, как упрощают, так и усложняют. Упрощают они визуальное восприятие исходников. Но поскольку являются строго l-value, усложняют использование при использовании их в качестве параметров функций. Прежде всего они разрушают стиль программирования Си, препятствуя прямой передаче выхлопа одной функции (r-value) в параметр другой, требуя для этого завести промежуточную переменную (l-value), плюс использование оператора присваивания. В результате имеем операторный стиль программирования типа паскаля/фортрана, кальку с древних методик расчета на рулончиках бумаги во времена докомпьютерной эпохи с сохранением промежуточных результатов на бумажном носителе (в оперативной памяти).
Множественное наследование -- бич С++. Из-за этого большие проекты на С++ вообще отказываются от наследования, используя включение, как более безопасный стиль программирования. Да и требуют меньшего напряжения  мозгов. Та благостная кртинка к графикой, где был базовый не обладающей конкретной геометрией примитив, набитый виртуальными функциями, и наследники с конкретной геометрией, так и остался только в рекламных материалах.  Не работает это.

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

Цитата: slavae от 17.11.2024 21:28:28А что если охлаждать компьютеры не радиаторами, а погружением в дистиллированную воду и фильтровать её постоянно от примесей? Или в спирт может быть.

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

Цитата: slavae от 17.11.2024 21:28:28А что если охлаждать компьютеры не радиаторами, а погружением в дистиллированную воду и фильтровать её постоянно от примесей? Или в спирт может быть.

Давно уже реализовано. Только не в спирт или воду, а в специальный теплоноситель. Небольшие кластеры для северов в таком виде выпускают. Сам  смонтирован в кунге, а на улицу выбрасывают радиатор. Собственно, на НСКФ до ковида можно было увидеть живьем и в работе.

Цитата: slavae от 17.11.2024 21:28:28А что если охлаждать компьютеры не радиаторами, а погружением в дистиллированную воду и фильтровать её постоянно от примесей? Или в спирт может быть.

Фторкетон, он же перфторэтил-изопропилкетон, он же Novec-1230.
Гуглим "Сухая вода". 
Диэлектрик. Температура кипения от 43 град, до 108, в в зависимости от того что намешали.

Небольшая статья на хабре про взлом биометрической системы https://habr.com/ru/…es/859394/
Из любопытного - удалось создать изображение лица, с успехом принимаемого системой за любого из двух разных пользователей.

Цитата: Luddit от 19.11.2024 12:41:17Небольшая статья на хабре про взлом биометрической системы https://habr.com/ru/…es/859394/
Из любопытного - удалось создать изображение лица, с успехом принимаемого системой за любого из двух разных пользователей.

изображение это не биометрия

Цитата: Поверонов от 19.11.2024 12:56:28изображение это не биометрия

Всю жизнь к биометрии относилось всё, по чему можно опознать голого человека.

Цитата: Luddit от 19.11.2024 13:44:30Всю жизнь к биометрии относилось всё, по чему можно опознать голого человека.

подмена задачи - опознание сгенерированного изображения вместо опознания фото живого человека - равнозначно идентификации по аватару

Цитата: Поверонов от 19.11.2024 14:01:53подмена задачи - опознание сгенерированного изображения вместо опознания фото живого человека - равнозначно идентификации по аватару

Подмена не там происходит. А там, где у вас написано "живого человека". Так что в серьёзных системах делают дополнительные ухищрения, чтобы эту самую живость проверить.

Цитата: Luddit от 19.11.2024 14:29:57Подмена не там происходит. А там, где у вас написано "живого человека". Так что в серьёзных системах делают дополнительные ухищрения, чтобы эту самую живость проверить.

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

Цитата: Поверонов от 19.11.2024 14:54:07да на паспорт ныне принимаются фотографии сделанные непосредственно в госучреждении изготовлящем паспорт - так проверяют "живость" Потому сгенерированные изображения годятся только для самопиара в соцсетях

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

Цитата: Luddit от 19.11.2024 12:41:17Небольшая статья на хабре про взлом биометрической системы https://habr.com/ru/…es/859394/
Из любопытного - удалось создать изображение лица, с успехом принимаемого системой за любого из двух разных пользователей.

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