На что перешли под Astra Linux?

А что все пакеты из репа астры таким образм описаны (вплоть до функций и переменных)?

Как ухитряются сертифицировать Астру я не знаю. Для нас, как конечных пользователей главное то, что весь дистрибутив Astra Linux SE сертифицирован.

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

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

Ну тогда переписывать на плюсах, видимо. Не завидую, особенно учитывая, что в LabVIEW практически ФП, и переносить эту логику на императивный язык… мдэ…

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

Я на работе подобную задачу (отказ от Labview в пользу хоть чего-то вменяемого) взял самостоятельно, когда с этим Labview работать пришлось. Правда, найти адекватной замены не смог, пришлось писать свою: https://github.com/COKPOWEHEU/MeasBot Она, конечно, неудобная, кривая и работает с полутора железяками. Но, по крайней мере, там используется нормальный текстовый язык программирования Lua. Собственно, реализовав один и тот же алгоритм сначала на Labview, а потом на Lua, стало совсем очевидно, насколько второе удобнее.

Нацполбаном. :(

Но, по крайней мере, там используется нормальный текстовый язык программирования

:)))))))))

Нацполбаном. :(

О, так может он где ещё ураганит до сих пор)

Я уж думал, что он, таки, иссяк…

Я немного в стороне от темы и обсуждения. А что мешало заранее создать зеркало Debian, и уже потихоньку добавлять проверенные (сертифицированные) пакеты в Астру? Также была бы возможность разработчикам адаптировать код под нынешние реалии. Понятно, что отставание в развитии будет, но во всяком случае не с нуля всё делать.

че, Qnx был совсем трешем?

QXN6/ЗОСРВ-Нейтрино - это хорошо, а вот QNX4.x это ужасная архаичная платформа, просто по юридическим сертификационным причинам эта дрянь задержалась на этом свете, это зомби. Очень убогие полурабочие отладчики, очень старые библиотеки, дохлые дедовские компиляторы. Приходилось делать код так, чтобы можно было профилировать и тестировать под Linux, затем компилять про это QNX4

Старая платформа, раньше кушали ДОС, но это как сейчас работать на перфокартах - смысла нет

К счастью, препятствия для перехода на Linux в ряде отраслей были устранены, причем еще в 2020 году

специфика АстраЛинукс может быть только в мандатном доступе, если пишите системные сервисы.

Для юзер формошлепов там проблем никаких нет. По версиям пакетов - Астра 1.8 будет на debian 12.

Пятый уже в общем-то вполне ничего :)

Кстати, почему пятый? ПятАЯ, наверное, система всё-таки.

А почему они эту таблицу сделали относительно Дебиана ? Насколько я помню в Астре дофига пакетов из Убунту.

Или в Дебиан тоже есть пакеты из Убунту ?

А почему они эту таблицу сделали относительно Дебиана ? Насколько я помню в Астре дофига пакетов из Убунту. Или в Дебиан тоже есть пакеты из Убунту ?

Первое предложение в Википедии:

Ubuntu (МФА [ʊˈbʊntuː]; от зулу ubuntu — «человечность»[10]; «Убу́нту») — дистрибутив GNU/Linux, основанный на Debian GNU/Linux...

https://ru.wikipedia.org/wiki/Ubuntu

я помню рассказы про дорогую и очень крутую ОС реального времени QNX где-то в 1997-м.

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

А зачем была нужна QNX в вашем случае? Там прям какие истории типа реального времени?

И что ?

Просто может по пакетам и версиям Астра ближе к какой то версии Убунты чем к какой то версии Дебиана. Не будут же они делать винегрет.

По крайне мере Астра как и Убунта на iso подписывает реп в отличие от Дебиан. В Дебиане почему то на исо, реп не подписывается и в апт стоит костыль, типа если ты ставишь локально с СД то плевать на наличие подписи.

файл : Release.gpg

Реальное время не использовалось, просто стабильнее. Эта ОС ровесник win 95, и по сравнению с ним это было космос

Но на что переползли (переползают) люди в важем окружении? Потому как не хочется лопухнуться….

1. Если смотреть со стороны работника, то всегда лучше осваивать ходовые, общеупотребительные технологии. В любом городе можно будет без труда устроиться на новую работу.
2. «Кьют» развивает одна контора. Если завтра хозяин этой конторы впадет в маразм или самодурство и закроет проект, то идти улицы мести из-за него? Между прочим, для нашей страны эта контора уже ввела торговые ограничения.
3. Я делал двухзвенное устройство ПО: сверхбыстрый сетевой алгоритм работает в одном процессе и передает и принимает данные на отрисовывающую часть в Интернет-обозреватель через ХТТП-запросы и ответы по РЕСТу во второй процесс. Особенность этого решения в том, что даже при полной загрузке сетевого звена взаимодействие с пользователем идет плавно за счет разделения процессов.

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

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

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

Надо учесть, что в Астре на Qt написан Fly. Соответственно, какая-то поддержка будет. В репозиториях Астры есть всё для разработки на Qt (хоть и немного устаревшее). Кроме того фанаты Qt говорят, что раз у нас есть исходники Qt и мы смогли их собрать, то значит риска нет (исходники можно взять с многочисленных зеркал, например).

Это не самый легкомысленный подход. Другие говорят, что нет риска ставить вообще любые библиотеки из Internet, превращать Астру в Убунту. Заказчик хочет Астру - будет ему Астра. Не его дело во что я её превратил.

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

Кроме того фанаты Qt говорят, что раз у нас есть исходники Qt и мы смогли их собрать, то значит риска нет (исходники можно взять с многочисленных зеркал, например).

1. Насколько мне известно, в открытых исходниках «Кьюта» выкладывается не всё, что «Кьют» умеет. Часть функций и обновления доступны только в закрытой платной версии.
2. Если техподдержка не нужна, а открытые возможности «Кьюта» и отсутствие его обновлений устраивают, то можно взять «Кьют» даром. Однако как только предприятие попытается продать своё ПО на основе «Кьюта» в какую-либо развитую страну, то с него сразу же попросят показать купленную лицензию «Кьюта» за каждое рабочее место разработчика. Сейчас просто не продадут эту лицензию.
3. Для разработчика эти ограничения рано или поздно приведут к сворачиванию использования «Кьюта» предприятиями по разработке ПО в нашей стране. А зачем вкладывать силы и время в то, что вымирает? Гораздо дальновиднее вложиться в вэб, который только идёт в гору.

Для разработчика эти ограничения рано или поздно приведут к сворачиванию использования «Кьюта» предприятиями по разработке ПО в нашей стране.

Вопрос от директора предприятия - с чего это вдруг? Если в вашей стране вчера/позавчера/в прошлом году успешно работал сертифицированный 5.15, что вдруг случилось что его сейчас нельзя использовать? пару ошибок закрыть не в состоянии? тыжепогромист или как? Если вы этого не умеете может мне вас уволить и нанять того кто умеет?

Вопрос от директора предприятия - с чего это вдруг?

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

Требования к ПО постоянно растут и технологии его разработки будут неизбежно обновляться.

бла бла бла..

Как это коснется тебя? Попробуй сегодня найти на рынке труда инженера по Вижуал бейсику или Фокспро - толковые люди не пойдут работать с отсталыми орудиями труда

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

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

ракеты летают в космос до сих под на технологиях 70х годов

У меня примерно такой же вопрос, но с уклоном в сторону легальщины.

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

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

1. динамическая загрузка кутэшных либ, имеющихся в системе? типа мы же их не таскаем с собой и не контрибутим.
2. закрытое ядро с бизнес-логикой и опенсорсный гуй который делает (1)?

делать коммерческое приложение со статической линковкой с опенсорсными либами

можно. Однако lpgp требует от тебя предоставить объектники своего приложения, чтобы можно было перелинковать его с другой (возможно модифицированной пользователем) версией библиотеки.

https://www.gnu.org/licenses/gpl-faq.en.html#LGPLStaticVsDynamic

Но это довольно неудобно, так что вариант 1 выглядит попроще.

как другие коллективы сделали переход на Астру

Собрали докер с астрой и добавили на CI сборку в нём. Но у нас продукт и до этого под дебианом работал.

1. в коммерческой части без исходников только свистелки с перделками
2. продавали ПО во Франции и в США, никто показать лицензию не просил.
3. сфигали. Как минимум есть Аврора Ростелекома.

LabVIEW

Вам п*дец. Делайте оценку разработки новой версии своего софта с нуля.

Астра Линукс - предельно убогий дистрибутив...

Жаль, что вас на МСВС не переводят, дабы вы действительно познали убогость.

На что перешли под Astra Linux?

«Героин, марихуана, крэк» (с)

На счёт перспектив лицензионной разработки на Qt в России вопрос спорный. Сомнения в любом случае есть. Но можно рассмотреть использование вэб и с практической точки зрения.

Как я понял, автор что-то разрабатывает для промышленности. То есть управляет какими-то устройствами и датчиками по протоколам типа модбаса. Ему потребуется сделать локальный http-сервер, который выполняет управление устройствами, и заодно обменивается данными с браузером. Тут есть вопросы:

1. Разработчику придётся изучить frontend на хорошем уровне, чтобы выглядело не хуже чем в Qt. Возрастает трудоёмкость, так?
2. Скорее всего придётся взять фреймворк для JavaScript. Тут нет риска с лицензиями?
3. Можно ли с помощью браузера сделать «киоск»? То есть ограничить доступ пользователя к управлению браузера и ОС, хотя бы для случая, когда у него нет клавиатуры.
4. Qt кроме GUI предоставляет дополнительные «батарейки» (сеть, sql, xml, com-порты и прочее). Разве браузер их предоставляет? Где их брать?
5. Код frontend-а будет открыт, так?

Разработчику придётся изучить frontend на хорошем уровне, чтобы выглядело не хуже чем в Qt. Возрастает трудоёмкость, так?

Писать на HTML’e, CSS’e и Javascript’e несложно. Красоту и удобство такого подхода ты можешь оценить, подойдя к ближайшему банкомату «Тинькова» и понажимав кнопки на его экране.

Скорее всего придётся взять фреймворк для JavaScript. Тут нет риска с лицензиями?

Можно и без фреймворка: HTML5, CSS3, Javascript. Фреймворков тоже полно полностью в исходных кодах и навечно бесплатных.

Можно ли с помощью браузера сделать «киоск»? То есть ограничить доступ пользователя к управлению браузера и ОС, хотя бы для случая, когда у него нет клавиатуры.

Конечно. Добавляешь ключ «–kiosk» в строке запуска твоего Интернет-обозревателя и отображение страницы станет полноэкранным, без меню и рамок, реакция на нажатие кнопок отключится.

Qt кроме GUI предоставляет дополнительные «батарейки» (сеть, sql, xml, com-порты и прочее). Разве браузер их предоставляет? Где их брать?

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

Код frontend-а будет открыт, так?

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

Однако lpgp требует от тебя предоставить объектники своего приложения.

Такого мы себе позволить не можем.
Ну вроде пункт (2) в твоей ссылке гласит, что при динамической линковке можно забить на открытие своих исходников? У меня туго с пониманием таких формулировок.

а вариант2: закрытое ядро и открытый гуй - нормально будет?

да и да

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

Но так устроен мир, что не все говорят на самом распространенном языке - китайском. Им проще говорить на своем испанском, чем учить китайский

Qt 6 уже вышел, будет и 7 и 27. И помирать не собирается. И быть может однажды https://wiki.qt.io/Qt_for_WebAssembly и Qt HTML5 backend выйдут на следующий уровень качества и интеграции

А еще есть сторонники PyQt и подобного

Им проще говорить на своем

Понятно, что при наличии кодовой базы на Qt правильно на нём и оставаться. А если код на чем-то более привязанном к Windows, то есть повод рассмотреть веб альтернативу. Например, у меня в поддержке много кода на C# и Windows.Forms. Это можно как-то на Mono перевести. Но новые проекты по такой технологии на Linux будут маргинальными. Также непонятны перспективы разработки на .Net Core и какой-нибудь Avalonia UI под Linux.

PyQt

Тут тоже есть сомнения:

1. Уже две лицензионные зависимости: от Qt и от PyQt.
2. У питона есть свои батарейки. Соответственно, Qt здесь не так важен как в C++.
3. Проблемы с переносимостью. Мои младшие коллеги писали на PyQt6 в Windows, а в Астре PyQt5. Не запустилось. Пришлось правки вносить.

В качестве альтернативы я писал на Tkinter-е. Там с переносимостью у меня проблем не возникло. Но на нём не очень приятно писать - если не брать базовые вещи, то нет интуитивности. Из доступной документации не поймёшь как реализовывать что-то хитрое. Приходится искать рецепты из Internet. Кроме того, Tkinter теряет популярность, становится маргинальным.

.net core 3.1 точно портирован не просто на Астра Линукс но и на платформу Эльбрус вообще, и Avalonia UI там волне живёт

«Бегите, глупцы!» (с)

Qt 6 уже вышел, будет и 7 и 27. И помирать не собирается …

Скажем честно, что «Кьюту» в России конец. Если его производитель настроен к нашей стране враждебно, то о каком взаимодействии может идти речь? Это как жить вместе с бабой, которая ненавидит своего мужика.

Никто в здравом уме сейчас начинать новые проекты на «Кьюте» в нашей стране не будет. Что останется? Развитие и сопровождение глючного старья. Тут я бы тоже особо не радовался. Один руководитель подобной старпердовской конторы уже высказался выше, что технологии 70-х годов это круто и его подчиненные будут писать на том, на чем он велит, а не на том, что лучше подходит для решения задачи. Проще говоря, загонят рабов в подвал и начнут зарплату задерживать - бежать-то рабам уже некуда с их устаревшими навыками. «И зачем вам деньги? У вас же есть огороды!», - такие заявления руководителей уже слышали наши отцы в смутные времена.

Ребята, чем дольше вы возитесь с этим «Кьютом», тем сложнее будет уходить. Куда уходить я уже написал. БЕ-ГИ-ТЕ!

Скажем честно, что «Кьюту» в России конец. Если его производитель настроен к нашей стране враждебно, то о каком взаимодействии может идти речь

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

Мы применяем же запрещенные процессоры AMD и ынтел от «враждебных фирм», которые даже аудит не провести

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

Там проблемы в другом.

1. Получается две зависимости: от Microsoft и от Google (Avalonia UI использует Skia).
2. C# хорош вместе со студией. А студии под Linux нет. Есть JetBrains Rider, но неизвестно насколько он хорош и как купить лицензию.

Никто не говорит о разработке, речь про возможность запускать и отлаживать софт, применять на платформе Linux, и не только на x86

Как я понял из дискуссии, подавляющее большинство разработчиков пилят разного рода «киоски» и аналогичный софт для финансовых нужд (банки, склады, интернет-магазины и т.п.), отсюда, видимо, появившееся в последнее время по результатам опросов преобладание использования Питона, C# и прочих маргинальных (ИМХО) языков программирования по сравнению с С/С++. На практике же, когда возникает потребность всосать данные с аппаратуры или, еще круче, вытолкать их в аппаратуру, да еще делать это на круглосуточной основе на протяжении многих месяцев без права взглюкнуть - на случай глюка тоже должен быть предусмотрен обходной путь, чтобы персонал смог выкрутиться… просто не видно альтернативы С/C++.

делать это на круглосуточной основе на протяжении многих месяцев без права взглюкнуть

Для этого как раз больше подходят Java, C#, Python, а не C++. Потому что у них есть сборщик мусора и нормальная система исключений. То есть в случае ошибок Python выдаст исключение, которое можно перехватить, а C++ может молча упасть.

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

И?

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

Зависит от требуемого времени реакции. В большинстве случаев в таких системах лучше избегать интерпретируемых языков и языков без строгой системы типов (С). Но если у тебя нет жёсткого лимита на время обработки, то java или C# не будут чем-то хуже C++. И там, и там исключения могут летать ото всюду, и там и там почти одинаковые средства для слежения за состоянием объектов. Возможно в C++ по-хуже с обеспечением exception safety, т.к. всякие деления на ноль и разыменования нулевого указателя в плюсах не обрабатываются системой исключений. При этом в C++ есть куда больше не очевидных подводных камней, которые могут ломать код произвольным образом. Писать на плюсах сложнее.

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

просто не видно альтернативы С/C++.

Внезапно, есть rust, и для надёжных систем он подходит лучше C++, python, java, c#, и тем более C, просто потому что там ещё более строгая система типов и обработка ошибок, принуждающая явно прописывать возможные пути развития событий и обрабатывать их все. В rust’е больше ограничений, но для систем от которых требуется в первую очередь надёжность это как раз хорошо.

И?

Ты переживаешь, что Джаваскрипт будет медленно отрисовывать страницу в Интернет-обозревателе? Дело в том, что страница отображается из HTML-разметки с CSS’ом, а Джаваскрипт лишь отрабатывает логику изменений, вносимых пользователем. Сам Интернет-обозреватель-то написан большей частью на «Крестах». Все быстро рисуется. Если однопоточность Джаваскрипта беспокоит, то в нем придумали многопоточные воркеры и алгоритм вполне можно распараллеливать, но на независимые друг от друга части.

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

Если взглянуть шире, то вэб создавали художники, а «Кьют» - рабочие. Широта и гибкость вэба заложена в исполнении Джаваскрипт-кода по ходу его исполнения, «на лету», то есть интерпретатором. Захотел пользователь разместить на экране три кнопки вместо двух и программа перерисовала страницу, как нужно. У «кьютистов» же все экраны нужно создать заранее, а программа лишь проходит по обработчикам изменений от пользователя и изменить страницу без заранее известного алгоритма вряд ли сможет.

Улавливаешь разницу в широте мышления двух подходов? И с кем ты останешься: с исполнителями, работающими строго по образцу, или творцами-вольнодумцами, создающими произведения искусства?

Да нет, гастролялекс и правда сосёт.

продолжай наблюдения, а главное - держи нас в курсе!

только не поганый, лучше Python/Tk он везде работает и шустро.

есть какой-то непоганый электрон? без браузера?

в случае ошибок Python выдаст исключение, которое можно перехватить

сука нет, вчера на Python столкнулся: телеграм бота набросал по быстрому: не оптимально, медленно. Обработку собщения обернул в try: except: pass.
Все работает хорошо когда одно сообщение, но если приходит два, три сообщения есть вероятность:
a) что всё нормально обработается,
б) что одно не обработается (ну ничего так и планировалось, но все равно странно ошибками в консоль сыпет будто нету try),
в)а самое главное всё может повиснуть, и обработка сообщений прекращается, но сама программа не завершается.
Сишное поведение молча упасть в данном случае оптимальное, хоть перезапустить молча можно.