Баганутость российского ПО (30.09.2022).

" title="Написать письмо">Написать письмо

Статьи по разделам

Статьи по дате (многие всегда актуальны)

Испытано на себе

Творчество

Прочие разделы

Вечно актуальные статьи

Статистика

Пользователи : 1
Статьи : 1951
Просмотры материалов : 7076459

Баганутость российского ПО (30.09.2022).

2022 - Сентябрь

30.09.2022 17:13

Save & Share

← Замена вентилятора видеокарты (22.09.2022).		Wagon Wheels (30.09.2022). →

~~ИА Панорама~~ КБ Панорама, продукт ГИС Конструктор/Оператор, отвечающий за отображение карт и рисование на их поверхности. Выявленные баги российской Astra Linux (а еще будет научная работа по поводу другой версии этой ОС) - это ничто, в сравнении с этим ПО. Возможно, унитаз российского производства поспорить сможет.

Требовалась тривиальная, на первый взгляд, задача: открыть карту, выделить область, сохранить область в файл PNG. В Windows эта задача решилась бы (наверное) простой функцией "что-то-там-Save-BMP" из крайне неинформативного руководства системного программиста ГИС. Но в линуксе ни одна простая задача не дается просто. Посмотрев похожий код в очень сложном проекте, выяснилось: код по ГИС настолько был переплетен с проектом, что вытащить его оттуда оказалось невозможным. Значит, тот, кто писал код, не обеспечил этому проекту должную модульность - и, вероятно, это было по вине больших трудностей написания: огромной трудоемкости и сил.

Напрягся от такой мысли. Было решено писать с нуля, заимствуя из проекта примерную парадигму работы с ГИС - но не функции, там встречающиеся. Как выяснилось, не зря (API-функции ГИС - корявые):
- пусть нужно вписать путь карты как входной параметр функции открытия. Но таких функций 3 - и все они работают одинаково, а требования к ним разные. В одной функции может быть все нормально, другая отказывается путь принимать, требуя свой тип данный WCHAR. При этом парадокс в том, что WCHAR ГИСа - это не wchar_t Linux или WCHAR=wchar_t Windows API. Самым легким вариантом оказалось использование функции, которая требовала char*, - и найти из множества способов конвертации данных рабочий: const char *cMap_Path = strData_SQL.strBZ[0].qsMap_Path.toUtf8().data(). В этот момент понимаешь: если такие "особенности" идут в самой же первой строчке кода - дальше будет засада;
- и эта засада не заставила себя ждать. Функции QDMapView (без нее русские символы не отображаются корректно) и mapOpenMap - уничтожают содержимое всех переменных char* в своей области видимости (даже если они const и не являются входными параметрами функции). Открыл карту с помощью mapOpenMap, указав путь const char*, - этот путь и все char* в округе станут пустыми или односимвольными (когда как);
- открытия карты - недостаточно для открытия карты. Карта без сетки и надписей - жалкое зрелище. И их подгружать бы автоматически или как параметр открытия - но нет: нужно подгрузить вручную еще 1 определенный файл. И зрелище не только жалкое, но и слепое: т.к. сохранение рисунка еще не реализовано, и визуального интерфейса нет, - фактического результата работы функций не видно - и остается только наблюдать возвращаемые ими значения, интерпретированные одинаково: "если вернула 0 - функция выполнилась ошибочно - расшифровать ошибку невозможно". И это полная дичь, потому что в нормальных функциях всегда возвращается код ошибки (0 - если норма). А некоторые функции - вообще void: отработают неправильно - и не узнаешь.

К неинформативности руководства системного программиста (например, про подключаемые LIBS - ни слова), в свою очередь, добавилась проблема: API-файлы имеют русскоязычные комментарии к коду - но они убиты сохранением этих файлов в неизвестной кодировке. Ни в Linux, ни в Windows (даже с использованием ПО Штирлиц) - эту кодировку H-файлов расшифровать оказалось невозможно.

Понимая, что вслепую работать практически нереально, - было решено идти в ТП. Был проведен анализ: предприятие закупило дохрена лицензий за последние 6 лет. И когда был отправлен запрос в ТП по указанной на сайте электронной почте для обратной связи - пришел исчерпывающий ответ: вали на форум. На форуме не работала корректно регистрация (невозможно войти по правильно введенным логину и паролю). Админы форума копались в моей учетке после запроса - и вот, наконец-то, смог открыть свою тему. Выяснилось, что форум мертвый: "пользователь" и админ, отвечающие на сообщения, - единственные ответчики и сотрудники ГИС. И один из них дал исчерпывающий ответ: вали в мануалы. Я им пишу в абсолютно корректной форме: "Вы что, уху ели, отказывать владельцу лицензий в техподдержке?". В результате, был дан исчерпывающий ответ: да вот тебе пример работы с картами.

А дальше начинается самое интересное:
- я написал им исчерпывающую информацию: название и версию ОС, среды программирования, установленного продукта ГИС, конкретную задачу (далее им на почту даже исходники были высланы на анализ). Им этого мало: начинают доеживаться, каким способом я пишу свое ПО. Сыпят скопированными функциями из руководства программиста, не объясняющего их сути. Не отвечают по почте вообще ни на что, в т.ч. на запрос предоставить расшифровку файлов в неверной кодировке;
- пример, выданный ими, имел фатальные ошибки, выявить которые помогли только навыки тестировщика. С учетом того, что пример они давали из мануалов новых версий, а у меня более старая версия, - все ошибки идут сквозь версии, и никто не думает их исправлять. Хотя стоит признать: без этого примера ничего бы не вышло;
- в конце всей этой канители выяснится: ТП отредактировала и собственные сообщения в теме, и мои. Цензура потрясающая - и ни один из приходящих на сайт пользователей не узнает ни абсурдности ситуации, ни багов их продукта (потому что и мое описание багов они тоже потерли).

А баги примера были волнующими:
- логично было бы выбрать кратчайший путь разработчикам ГИС - и написать в API ГИС функцию, сжирающую 2 точки координат, строящую по ней прямоугольник и готовящую этот прямоугольник для сохранения в файл. И функцию сделать перегруженную: чтобы и текстовые координаты принимала, и радианные, и тип системы координат. Но нет: текстовые координаты должны быть преобразованы именно в радианы, радианы - в метры на местности, метры на местности - в пиксели. Еще это все зависит от масштаба карты, выполняется в строгой последовательности отдельных функций или вообще своими руками;
- при работе с большими изображениями (которые, "внезапно", нужны для печати карт на A0), происходило скрытое переполнение входного параметра их функции AllocateTheMemory. В результате, в изображение сохранялась дичь, иногда даже повернутая на произвольный угол и кусками пустая (а ты, тем временем, еще на себя бочку катишь, думая, что сам написал ошибочный код);
- для правильного двойного вызова функции mapPlaneToPicture (2 же точки) требуются жесткие условия в метрах на местности: X1<X2, Y1>Y2. Если не распарсить входные координаты по этим абсурдным правилам - в рисунок будет сохраняться совершенно другой участок карты. Это было выведено имперически: естественно, никаких комментариев по координатам на эту тему не было - попробуй, догадайся;
- совокупность масштаба карты и диапазона координат - приводит к большим ширине и высоте сохраняемого изображения. В функции подготовки изображения для сохранения в файл mapPaintToXImage это не анализируется - последующий объект QImage, в итоге, скрыто крашится. Или второй вариант: даже malloc не хватит для корректного выделения нескольких гигабайт памяти. То есть, для корректного сохранения рисунка нужно не просто контролировать, чтобы изображение не выходило за (2²⁹-1) 4-байтных пикселей по объему, - но и изменять масштаб (порождая при этом соответствующие ограничения показа участка карты).

А ведь это всё - только описание действия сохранения участка карты в файл. Это не более 15% итоговой работы.

Назрел простой вопрос, как по Linux, так и по ГИС: зачем такое забагованное, алогичное и труднообслуживаемое говно внедряется в оборонной промышленности? Ведь это диверсия не только по отношению к программистам (сколько их поувольнялось при переходе с Windows на Linux - подумать страшно). Но и к обороноспособности страны в целом. А ответ известен: Сноуден в свое время про закладки в ОС, ПО и железо - сказок СБ-шникам понарассказывал. И наверху запретили Windows, полностью, - а альтернативы-то нет. И вместо изучения Windows и выпуска отдельных исправлений для устранения закладок в ОС (если они вообще существуют) - была написана "своя" Linux. "Своя" - потому что на импортном ядре Debian (его разработчик - Software in the Public Interest, Нью-Йорк, США).

(добавлено 02.10.2022) Потрясающий ответ от ТП. Они считают баг - фичей (даже заскринил свой ответ на него, на память: а то потрут еще). Потому что между 3-мя первыми ответами по теме (если будете искать) было мое сообщение - и теперь оно тоже стерто. Что примерный алгоритм не может быть ответом ТП на вопрос (как и сыпание функциями из справочника простой копипастой). Собственно, их примерный алгоритм с кучей ошибок - и является примером такого ответа, повлекшего кучу потраченного времени и гемора. У меня уже готова функция, сохраняющая прямоугольник с координатами корректно, - но она в корне отличается от предоставленного примера. И самоконтроль в этой функции пришлось делать встроенный, обрабатывая не только глюки API ГИС, но и технические ограничения среды Qt.

И еще баг обнаружился. В зависимости от масштаба, надписи на слое информации по инфраструктуре карты - плывут. При сохранении одного и того же участка карты: в масштабе 1:5000 надпись написана четко по центру лесной области, а при 1:50000 - улетает за пределы этой области влево и, как следствие, обрезается в сохраняемом рисунке.

(добавлено 03.10.2022) Потерли, кто бы сомневался.

(добавлено 04.10.2022) И еще один баг в примере от ТП. Функции mapCloseMapAccess и mapCloseData должны быть поменяны местами, т.к. в глубинах руководства системного программиста нашелся комментарий «освободить ресурсы ядра перед закрытием приложения». А закрытие карты, оказывается, в том же руководстве, - и описывается как закрытие приложения.

Также пришла информация от сотрудников другого подразделения по месту работы. Там все то же самое: плюются от багов ГИС, их сообщения о багах трутся с форума. И, самое главное, ТП использует чужой труд для нахождения багов в своем продукте. То есть, меня поимели, т.к. я выступил бесплатным тестировщиком их продукта в контексте примера ТП.

(добавлено 05.10.2022) Чтобы было понятно более простым языком о баганутости этого софта. Вот так выглядит точная карта Пакистана в масштабе >1:200.000, по мнению программы ГИС. Внутри API ГИС: скорее всего, повреждается выделенная память при формировании изображения.

(добавлено 18.02.2023) Гуглим на хабре "Программное обеспечение на российской ОС" пользователя MAXPribalt. Ее можно на цитаты разбивать: "ИТ-архитекторы поддакивали, а технический персонал никто слушать не стал", "бег по граблям с энтузиазмом". Статья - 2022 года, что намекает, что за 8-10 лет ни черта не изменилось.

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

(добавлено 30.08.2023) При подготовке миграции на другую версию Linux - вышло 2 перла:

- от разработчика Astra: даже нормально запаковать репозиторий Develop не могут. Это не tar, а tar.gz - и после распаковки gzip еще нужно распаковывать как tar;

- от разработчика ИА Панорама: руководство программиста от 2023 года имеет дату на заголовочной странице "2014". Количество листов больше, чем в имеющемся на руках руководстве от настоящего 2014 года. 9 лет не исправляли дату - и никто не обратил на это внимания.

Ну как можно работать с такими рукожопами, а...

Теги:

Обновлено ( 30.08.2023 19:32 )

Статьи по разделам

Статьи по дате (многие всегда актуальны)

Испытано на себе

Творчество

Прочие разделы

Вечно актуальные статьи

Статистика

Последние теги

Самые популярные теги

Самые читаемые теги

Случайные теги

Последние новости