есть электронные каталоги, базы данных. Они в основном «верстаются» без кириллицы в индексируемых полях.

Более того: что написано на корпусе процессора в заказе МО вы явно не в курсе.

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

А МЦСТ не занимается производством микроэлектроники, он занимается её разработкой.

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

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

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

А Вы не хотите предъявить претензии либералам, которые правили в 90-х. Там Рыжковым, Касьяновым, Ходорковским. Ну, Немцова уже нет. В результате которых у нас не только была тотально разрушена электронная отрасль, но и отсутствовали деньги на ее восстановление? На западе электронная промышленность развивается уже лет 70. А у нас лет десять потому, что первые годы, у нас тупо не было денег на ее развитие

Коллеги, организм просит бана направленной клеветой и оскорблениями.

я сказал как факт. Но зато компетенции часто очень быстро утрачиваются. Например, с топливом для АЭС (по договору ВОУ-НОУ).

Теперь технологией превращения оружейного урана в топливo для АЭС обладает только Россия.

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

Случаем шампанское за него не пили?   

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

А мужики-то не знают!

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

С дружественного ресурса…

 https://aftershock.news/?q=node/638199 

по-моему, буйный… ©

Цифры как раз пишутся справа-налево: единицы, десятки, сотни и порядки далее.

Цифры индийские 100%, потому что пишутся слева-направо, а не наоборот как у арабов.

мало того ,что русофоб ,так ещё и безграмотный,в арабском ЦИФРЫ записываются слева-направо ,как везде.

Термин «засыпались» не развертывается. Нельзя ли пояснить, что хотели сказать.

Есть ещё один положительный момент: тестирование под Linux выявляет ошибки, не замеченные под Windows.

У нас в Nanosoft, к примеру, преобладают определенные надежды связанные с Wine. Даже тестировали с партнерами. Но после очередного обновления версии нашего .NET API, засыпались на Mono.

Свяжитесь с Etersoft, если ещё не; и посмотрите вместо моны на dotnet-core, в альте собрано (как раз коллегами из Этерсофта).

Кстати, у нас вроде бы есть место общения для разработчиков, переносящих наработки с винды (и в т. ч. на .NET) -- как вариант, черкните на почту, постараюсь состыковать. И ещё наш партнёр в части организации поддержки -- ALP -- вроде как озадачился и поддержкой разработчиков тоже.

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

Отставить панику, есть рецепты    

Во-первых, сборка на чём-нить вроде centos6 поможет не выскакивать за ABI, который есть на любом более богатом дистрибутиве (если нужна какая более новая версия Qt -- осмысленно линковаться _с ней_ статически, т. е. делать semistatic; но это, как понимаю, не ваш случай).

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

В-третьих, можно собрать под наиболее удобный вариант и поставлять готовые образы виртуальной машины с ним (+/- flatpak какой).

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

Ну и до кучи: altlinux.org/migration

> А кто будет платить за переход на Linux?

А кто платил за переход на mysql, postgresql?

> На данном этапе спрос на решения под Linux ничтожно, а возни с переходом море.

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

> Тем более, что проприетарный софт не может распространяться в исходниках, а собирать под все Linux-подобные системы, даже пусть только находящиеся в реестре отечественного софта, это застрелится!

Вот тут вы выстрелили в самую мякотку. Проприетарный софт с моделью «продажа копий» действительно очень хреново масштабируется на несколько платформ вообще, а «триллион версий линукса» для него труднопреодолимое препятствие. Но есть и другие модели — OpenCore, например. Когда ядро открыто под той или иной лицензией, и разрабатывается совместно с сообществом, а продаётся «обвес», саппорт, заказные фичи. Проблема в том, что тот же Open Core — это заявка на «законодателя мод» и весьма рискованная. У нас нет бизнесменов с такой комбинацией амбиций и уверенности.

в комментариях иногда отмечается их представитель; он подробнее может рассказать.

А я собственно со слов этого представителя и пишу.

Он говорит практически тоже самое что и Константин (выше) — кто будет платить за переход на Linux?

«Для чего в нём латиница» — и как надо было ответить?

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

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

В данный момент ситуация такая — не далее как на прошлой неделе один из моих коллег наглухо положил базу данных компонентов просто по ошибке написав киррилическую «С» вместо латинской в партномере очередного чипа, который он в нее вносил. Благо проблема известная и была быстро устранена.

А в одном из популярных графических редакторов схем, люди, чтобы оформлять документацию по ГОСТ — рисуют кириллические буквы и собирают их в слова в Основной надписи.

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

Не везде. Некоторые САПР настолько консервативны, что попытка ввести что-то не латинское вываливается проблемой в пути и в файлах. Например, я работаю с программами от Xilinx ISE/Vivado и Intel(Altera) Quartus. У них есть особенность: они категорически не любят нелатинские буквы в пути, порой даже пробел является проблемой (в старых версиях). И Xilinx не может в UTF-8 (только Windows-1251) в отличие от Intel(Altera), что доставляет мне массу проблем с кириллическими буквами при переносе файлов из одного проекта в другой. В конечном итоге я стал работать только в Visual Studio Code, а синтезирую проект уже в самих программах, не забывая про правильность имён в пути. Так что юникод пока ещё не везде есть.

Систему команд SPARC V9 c SIMD расширениями VIS1 и VIS2 МЦСТ лицензировала у Sun Microsystems. А микроархитектуру можно разрабатыать какую угодно. Интел, к примеру, не разрешает никому использовать свою систему команд и не лицензирует ее. Исключением стали только AMD и VIA (на самом деле были еще и другие, но они давно ушли с рынка), которые успели «позаимствовать» систему команд еще во времена i80386.