Вы, как и многие другие в этой теме, упускаете из виду что сам процесс возврата не сможет оправдать затрат никогда и ни при какой системе.
Неверно. Ваш тезис корректен только для нормального мира с нормальным рынком.
Стоимость конечных изделий будет баснословной, массовости производства не будет в принципе, как следствие качество изделий будет ужасным по сравнению с тем что производится в других странах (не будет смысла их так отлаживать — потому что любой отстой купят за неимением альтернатив, и за любые деньги, кстати).
Возражаю.
У нас не Китай чтоб внутренний рынок мог переварить всё что будет произведено. (да и даже у Китая не мало экспорта).
Но ведь это взаимосвязанные процессы: востребованность товара -> производство -> рабочие места -> покупательская способность -> востребованность товара
Просто начать эту цепочку придётся с другой стороны… Безвозвратно похоронив в неё много ресурсов.
Мы говорим о несколько разных вещах. Вы в очередной раз говорите что в нормальном рыночном мире это экономически нецелесообразно. И с этим никто из комментаторов не пытается спорить. Это факт с которым глупо спорить.
Но статья представилась как рассуждения о технической возможности в условиях отсутствия нормального рыночного мира. Но что в статье, что в комментариях мы опять упираемся в тезис что в условиях рынка это не сработает.
В очередной раз призываю посмотреть только на техническую сторону вопроса, в условиях отсутствия или сильно ограниченности внешнего рынка.
Если разложить оборудование и сырьё до базовых полезных ископаемых — всё ещё нет всего необходимого? (безусловно нет, найдётся что-нибудь редкоземельное что есть лишь на одном континенте мира и заменить нечем — вопрос сколько такого и на каких этапах потребуется?)
Я понимаю что пройти путь из бронзового века в 21й заново это ДОЛГО (даже с учётом имеющегося опыта). А с учётом глобальной интеграции бессмысленно.
Но сейчас сильно поменялись переменные в формуле… Ключевым по прежнему останется человеческий фактор. Но если рассматривать только техническую сторону вопроса, то на мой взгляд человек прав. Это вопрос десятилетий вернуться на сегодняшний уровень, но не принципиальная невозможность.
И да это будет только вернуться, пока остальные будут двигаться вперёд. Ни о каких догнать и перегнать речи не будет. Но если это сделать — получится очень крепкий фундамент очень на долго.
К сожалению не всё.
Нужна именно координация всех кто согласится вкалывать (если согласится и <подставить кучу неудобных вопросов>).
Если (условно) в разных частях страны решат делать и применять разные «болты» — будет как рассказал автор в статье. Масштабно, дорого и бесполезно.
А если рассматривать более комплексно, когда оборудование нужно не только для микроэлектроники? Я понимаю что именно для микроэлектроники много специфичного. Но возможно по многим пунктам возможна унификация с чем то ещё.
Конвейерные системы, инженерные системы помещений, корпуса станков, какая-то ещё мелочь. Что-то по химической части наверняка будет иметь пересечения с другими химическими производствами.
Да, стоимость всё ещё уникальных для микроэлектроники компонентов станков останется космической. Так же как стоимость уникальных компонентов для других производств.
Но при такой глобальной унификации цена отдельных компонентов может перестать быть критичной.
Конечно такое возможно только при очень глобальном планировании на уровне государства. Но думаю в целом возможно.
Опять же, если считать очень грубо (понимаю, что все мы здесь привыкли к уровню жизни… но давайте применим условность и оставим это за кадром?) цена любого производства это еда и энергия, которая посредством «человеков» конвертируется по какому то курсу (время) в результат. Энергия есть, еда есть. Времени меньше чем хотелось бы, но пока есть. То есть какой то принципиальной невозможности сделать нет.
Думаю сейчас всё зависит от того, есть ли у имеющих власть сейчас какой то реальный план и согласованность действий. Наблюдаем.
Вариант первый модифицированный.
p1 — Национальный УЦ (со всей инфраструктурой) — поднять и обеспечить функционирование и выдачу сертификатов.
p2 — сертификация устройств — не поддерживаешь сертифика — не получаешь ростест, не можешь ввозить и продавать.
p3 — требования к распространению продуктов на территории РФ.
Это бизнес. Им всем проще будет добавить в версию дистрибутива для РФ нужный сертификат. Будет ли он признаваться или работать где-то ещё, вопрос отдельный и из другой плоскости. Если наша изначальная задача стоит обеспечить адекватный https для наших сервисов внутри страны.
И разумеется даже в этом случае произойдёт всё не мгновенно. Но это будет существенная подвижка в вопросе.
Ну он не сторонний. Он просто в отдельном Cmake со своими заморочками.
Большой проект в котором много модулей. Которые отдельно в том числе собираются на CI. В идеале вообще доделать Cmake скрипты, чтоб они вызывали анализ и формировали отчёт по таргету и как раз мета файл, который так же инсталился бы потом с либой для дальнейшего использования при проекте следующих проектов цепочки.
но, пока что это придётся делать вручную (через ядро pvs-studio).
Всмысле есть возможность самостоятельно написать плагин для этого или вызвать что-то из инструментария pvs, или речь о том что потенциально это есть, но никак недоступно пользователям?
И ещё немного не по теме… PVS пока не умеет анализировать конфигурации в WSL совсем из Clion, или требуется донастройка, установка самого PVS в WSL или что-то такое?
Вот подскажите про межмодульный анализ в вашем анализаторе.
Вариант первый. Есть модули A и B допустим в одном Cmake проекте. технически пусть это будет библиотека и исполняемый файл его использующий. Допустим анализ делается через Clion. В таком варианте при межмодульном анализе при проверке исполняемого файла будут учитываться вычисленные виртуальные значения библиотеки B?
Если ответ да — более сложный вопрос.
Есть у нас проект A. В проект A входит библиотека B.
Компилируются они по отдельности.
Можно ли как то сделать файл метаданных или чего нибудь ещё по библиотеке B, чтоб при анализе проекта A использовались выведенные для B ограничения значений и вот это всё?
Ну то есть для основной компиляции есть хидеры и скомпилированная либа, а для анализа хидеры и какая то скомпилированная метаинформация?
Подскажите пожалуйста по закрытости архитектуры и вот этому всему. Возможно уже где-то разбиралось…
С точки зрения разработки и производства — архитектура принадлежит кому то в МЦСТ и выпускать эмуляторы, аналогичные по архитектуре процессоры и так далее — незаконно?
С точки зрения разработки системного ПО — ассемблер не предоставляется вообще, предоставляется не полный с ограничениями, ..? Возможно ли создание своего компилятора (технически, юридически) под данную архитектуру?
С точки зрения разработки прикладного ПО — доступность SDK, компиляторов, инструментария, эмуляторов, ...?
Просто ЕАП обычно стабильны, и такие моменты вызывают удивление :)
Да. При некоторых Exception и вот почему то при запуске после падения по out of memory.
Причём прокси умирает сразу во всех подсистемах. Из окна настроек тестовый конект не проходит, маркет плагинов не обновляется, репорты не отправляются.
Перезапуск всё лечит.
Ещё когда встаёт новая версия и происходит импорт настроек из старой — тоже бывает история с тем, что прокси не срабатывает и не даёт подключить лицензию с аккаунта. Приходится включать в триал и потом уже подключать аккаунт после полной загрузки среды.
Спасибо за релиз.
Но это был первый случай, когда мне пришлось с EAP откатываться на стабильную версию. На одном из промежуточных патчей Clangd стал есть памяти как не в себя (до полного out of memory) и не поддавался никакому контролю. В релизе вроде починено.
И ещё при возникновении ошибок в Clion не всегда удаётся их отрепортить. Периодически при ошибках в Clion отваливаются настройки прокси (или авторизации на ней) и отправить отчёт из формы не удаётся. А после перезапуска прокси снова работает, но отчёта уже нет.
В остальном — ждём дальнейшего развития :)
VirtualBox (по крайней мере из последних) работает совместно с wsl2.
Но надо явно ставить машине интерфейс паравиртуализации в kvm и в некоторых случаях обязательно включать ускорение 3д графики.
В своих юзкейсах (десктоп Ubuntu ) потратил пару часов на выяснение какого чёрта (ускорение 3д графики, без него падала оболочка в убунте) и заметил снижение скорости работы виртуальной машины, но не критичное.
Кушает она столько же как и раньше. Почти 300 метров памяти.
И для формочки на несколько кнопок с иконками это непростительно дофига.
Ещё она не умеет сразу отдавать информацию о лицензии в свежеустановленную и запущенную среду разработки. И для каждой надо настроить прокси, залогиниться в аккаунт,….
В целом вроде удобно. Но то сколько она жрёт в отношении того сколько она делает — крайне грустно.
А я открывая статью надеялся на рекламу какого нибудь антивирусного решения для зеркал исходного кода и зеркал репозиториев Maven, NPM,….
А тут банально, скачал какой то бинарник и схватил вирус. Ну каждая первая история такая. История то в чём?..
У меня по этому пункту вопрос ко всей инфраструктуре JS.
У меня ушло много времени, чтоб заставить npm работать в изолированной от интернета среде.
Нет, справедливости ради — заставить сам npm это одна переменная окружения или один параметр к нему. Но вот подготовить зеркало репозиториев NPM и так чтоб он был не кеширующим самостоятельно бегающим в интернет, а нормальным зеркалом с ручным управлением — это была боль.
А если разработчику на той же ноде с тем же NPM задать вопрос «как с этим работать без интернета?» у них картина мироздания рушится.
И это глобальная проблема современного менеджмента зависимостей. Тот же мавен с одной стороны да, легко раздаётся любым веб сервером из списка файлов. С другой стороны сформировать этот список файлов по списку зависимостей, так чтоб собрать зависимости зависимостей задача уже не такая простая.
Это какая-то глобальная тенденция современной разработки. Системы управления зависимостями не представляют современный мир без интернета.
Относительные пути решают только часть этой проблемы.
В другом месте может оказаться сама Delphi.
Или из-за некорректно настроенного окружения первая оказавшаяся в PATH dcc может оказаться не той версии что тоже всё сломает.
Это работает только в одном строго фиксированном окружении. Любое изменение (безусловно его может не быть если у человека ровно один проект) и всё надо начинать сначала.
Но даже для такого сценария больше подошёл бы git с хуком на пуш, автозапуском скрипта и отправкой уведомления на почту по завершению.
Но кроме перечисления потенциальных проблем я ничего плохого в адрес решения сказать не могу. Все мы начинали с чего-то такого :)
Всеми руками за. Потому что у меня сейчас более примитивное решение и с ним скоро начнутся проблемы.
Это можно сделать как раздел в контексте статьи про CI.
Неверно. Ваш тезис корректен только для нормального мира с нормальным рынком.
Возражаю.
У нас не Китай чтоб внутренний рынок мог переварить всё что будет произведено. (да и даже у Китая не мало экспорта).
Но ведь это взаимосвязанные процессы: востребованность товара -> производство -> рабочие места -> покупательская способность -> востребованность товара
Просто начать эту цепочку придётся с другой стороны… Безвозвратно похоронив в неё много ресурсов.
Мы говорим о несколько разных вещах. Вы в очередной раз говорите что в нормальном рыночном мире это экономически нецелесообразно. И с этим никто из комментаторов не пытается спорить. Это факт с которым глупо спорить.
Но статья представилась как рассуждения о технической возможности в условиях отсутствия нормального рыночного мира. Но что в статье, что в комментариях мы опять упираемся в тезис что в условиях рынка это не сработает.
В очередной раз призываю посмотреть только на техническую сторону вопроса, в условиях отсутствия или сильно ограниченности внешнего рынка.
Я понимаю что пройти путь из бронзового века в 21й заново это ДОЛГО (даже с учётом имеющегося опыта). А с учётом глобальной интеграции бессмысленно.
Но сейчас сильно поменялись переменные в формуле… Ключевым по прежнему останется человеческий фактор. Но если рассматривать только техническую сторону вопроса, то на мой взгляд человек прав. Это вопрос десятилетий вернуться на сегодняшний уровень, но не принципиальная невозможность.
И да это будет только вернуться, пока остальные будут двигаться вперёд. Ни о каких догнать и перегнать речи не будет. Но если это сделать — получится очень крепкий фундамент очень на долго.
Нужна именно координация всех кто согласится вкалывать (если согласится и <подставить кучу неудобных вопросов>).
Если (условно) в разных частях страны решат делать и применять разные «болты» — будет как рассказал автор в статье. Масштабно, дорого и бесполезно.
Конвейерные системы, инженерные системы помещений, корпуса станков, какая-то ещё мелочь. Что-то по химической части наверняка будет иметь пересечения с другими химическими производствами.
Да, стоимость всё ещё уникальных для микроэлектроники компонентов станков останется космической. Так же как стоимость уникальных компонентов для других производств.
Но при такой глобальной унификации цена отдельных компонентов может перестать быть критичной.
Конечно такое возможно только при очень глобальном планировании на уровне государства. Но думаю в целом возможно.
Опять же, если считать очень грубо (понимаю, что все мы здесь привыкли к уровню жизни… но давайте применим условность и оставим это за кадром?) цена любого производства это еда и энергия, которая посредством «человеков» конвертируется по какому то курсу (время) в результат. Энергия есть, еда есть. Времени меньше чем хотелось бы, но пока есть. То есть какой то принципиальной невозможности сделать нет.
Думаю сейчас всё зависит от того, есть ли у имеющих власть сейчас какой то реальный план и согласованность действий. Наблюдаем.
p1 — Национальный УЦ (со всей инфраструктурой) — поднять и обеспечить функционирование и выдачу сертификатов.
p2 — сертификация устройств — не поддерживаешь сертифика — не получаешь ростест, не можешь ввозить и продавать.
p3 — требования к распространению продуктов на территории РФ.
Это бизнес. Им всем проще будет добавить в версию дистрибутива для РФ нужный сертификат. Будет ли он признаваться или работать где-то ещё, вопрос отдельный и из другой плоскости. Если наша изначальная задача стоит обеспечить адекватный https для наших сервисов внутри страны.
И разумеется даже в этом случае произойдёт всё не мгновенно. Но это будет существенная подвижка в вопросе.
Большой проект в котором много модулей. Которые отдельно в том числе собираются на CI. В идеале вообще доделать Cmake скрипты, чтоб они вызывали анализ и формировали отчёт по таргету и как раз мета файл, который так же инсталился бы потом с либой для дальнейшего использования при проекте следующих проектов цепочки.
Всмысле есть возможность самостоятельно написать плагин для этого или вызвать что-то из инструментария pvs, или речь о том что потенциально это есть, но никак недоступно пользователям?
И ещё немного не по теме… PVS пока не умеет анализировать конфигурации в WSL совсем из Clion, или требуется донастройка, установка самого PVS в WSL или что-то такое?
Вариант первый. Есть модули A и B допустим в одном Cmake проекте. технически пусть это будет библиотека и исполняемый файл его использующий. Допустим анализ делается через Clion. В таком варианте при межмодульном анализе при проверке исполняемого файла будут учитываться вычисленные виртуальные значения библиотеки B?
Если ответ да — более сложный вопрос.
Есть у нас проект A. В проект A входит библиотека B.
Компилируются они по отдельности.
Можно ли как то сделать файл метаданных или чего нибудь ещё по библиотеке B, чтоб при анализе проекта A использовались выведенные для B ограничения значений и вот это всё?
Ну то есть для основной компиляции есть хидеры и скомпилированная либа, а для анализа хидеры и какая то скомпилированная метаинформация?
С точки зрения разработки и производства — архитектура принадлежит кому то в МЦСТ и выпускать эмуляторы, аналогичные по архитектуре процессоры и так далее — незаконно?
С точки зрения разработки системного ПО — ассемблер не предоставляется вообще, предоставляется не полный с ограничениями, ..? Возможно ли создание своего компилятора (технически, юридически) под данную архитектуру?
С точки зрения разработки прикладного ПО — доступность SDK, компиляторов, инструментария, эмуляторов, ...?
Да. При некоторых Exception и вот почему то при запуске после падения по out of memory.
Причём прокси умирает сразу во всех подсистемах. Из окна настроек тестовый конект не проходит, маркет плагинов не обновляется, репорты не отправляются.
Перезапуск всё лечит.
Ещё когда встаёт новая версия и происходит импорт настроек из старой — тоже бывает история с тем, что прокси не срабатывает и не даёт подключить лицензию с аккаунта. Приходится включать в триал и потом уже подключать аккаунт после полной загрузки среды.
Но это был первый случай, когда мне пришлось с EAP откатываться на стабильную версию. На одном из промежуточных патчей Clangd стал есть памяти как не в себя (до полного out of memory) и не поддавался никакому контролю. В релизе вроде починено.
И ещё при возникновении ошибок в Clion не всегда удаётся их отрепортить. Периодически при ошибках в Clion отваливаются настройки прокси (или авторизации на ней) и отправить отчёт из формы не удаётся. А после перезапуска прокси снова работает, но отчёта уже нет.
В остальном — ждём дальнейшего развития :)
Но надо явно ставить машине интерфейс паравиртуализации в kvm и в некоторых случаях обязательно включать ускорение 3д графики.
В своих юзкейсах (десктоп Ubuntu ) потратил пару часов на выяснение какого чёрта (ускорение 3д графики, без него падала оболочка в убунте) и заметил снижение скорости работы виртуальной машины, но не критичное.
И для формочки на несколько кнопок с иконками это непростительно дофига.
Ещё она не умеет сразу отдавать информацию о лицензии в свежеустановленную и запущенную среду разработки. И для каждой надо настроить прокси, залогиниться в аккаунт,….
В целом вроде удобно. Но то сколько она жрёт в отношении того сколько она делает — крайне грустно.
А тут банально, скачал какой то бинарник и схватил вирус. Ну каждая первая история такая. История то в чём?..
У меня ушло много времени, чтоб заставить npm работать в изолированной от интернета среде.
Нет, справедливости ради — заставить сам npm это одна переменная окружения или один параметр к нему. Но вот подготовить зеркало репозиториев NPM и так чтоб он был не кеширующим самостоятельно бегающим в интернет, а нормальным зеркалом с ручным управлением — это была боль.
А если разработчику на той же ноде с тем же NPM задать вопрос «как с этим работать без интернета?» у них картина мироздания рушится.
И это глобальная проблема современного менеджмента зависимостей. Тот же мавен с одной стороны да, легко раздаётся любым веб сервером из списка файлов. С другой стороны сформировать этот список файлов по списку зависимостей, так чтоб собрать зависимости зависимостей задача уже не такая простая.
Это какая-то глобальная тенденция современной разработки. Системы управления зависимостями не представляют современный мир без интернета.
В другом месте может оказаться сама Delphi.
Или из-за некорректно настроенного окружения первая оказавшаяся в PATH dcc может оказаться не той версии что тоже всё сломает.
Это работает только в одном строго фиксированном окружении. Любое изменение (безусловно его может не быть если у человека ровно один проект) и всё надо начинать сначала.
Но даже для такого сценария больше подошёл бы git с хуком на пуш, автозапуском скрипта и отправкой уведомления на почту по завершению.
Но кроме перечисления потенциальных проблем я ничего плохого в адрес решения сказать не могу. Все мы начинали с чего-то такого :)
Это можно сделать как раздел в контексте статьи про CI.