Мучения с миграцией порождены, в основном, приказом от ~2014 года сами знаете кого "переходите на все отечественное"; и с тех пор у программистов не только госсектора - жопа в мыле, причем бессмысленно намазанная. Требуется перенос ровно такого же функционала на другую ОС - и трудозатраты по переписыванию исходников гигантские. С Windows на Linux, с импортного Linux на российский Linux, с российского Linux на российский Linux того же производителя (этот случай) - всюду треш.

На этот раз нелегкая занесла в огромный программный комплекс:
- 34 подпроекта в проекте. Размер каждого, без учета общих файлов, - десятки и сотни килобайтов только .CPP- и .H-файлов;
- взаимодействие с операционной системой, программой ГИС, сторонним программно-аппаратным комплексом, сторонним программным комплексом;
- много математики и ее визуализации на двух мониторах.

Миграция осложняется:
- почти 10-летней разницей между Astra Linux SE v.1.4 и Astra Linux SE v.1.7.4.0. Это равносильно переходу с Windows 98 на Windows 7: драйвера, API, кроссплатформенность - идут лесом. Заявленная кроссплатформенность Qt вообще ни одной практической миграцией не подтвердилась - переписывать много приходится;
- глючит и ОС, и ГИС, и Qt - причем в каждой версии свои баги. Даже билд в версии имеет значение (например, разница между астрами 1.7.0.0 и 1.7.4.0 - 22мес);
- большая разница и версий Qt, и версий GCC в их составе;
- на такой огромный программный комплекс нужно выделять нескольких тестировщиков - в реале нет ни одного;
- на такой огромный программный комплекс нужно выделять нескольких программистов - в реале только один (угадайте, кто);
- заказчик без конца сыпет новыми задачами;
- модульность проекта отсутствует из-за их слияния друг с другом, путем использования папки с общими исходниками. Изменение общих исходников в лучшую сторону для одного модуля может привести к неработоспособности другого.

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

Подготовка к миграции включала в себя:
- изучение ОС на предмет ее API. Выяснилось, что многие h-файлы существуют в нескольких одноименных вариантах. Значит, требуется еще и SSD для быстрого поиска по файловой системе, в т.ч. полнотекстового;
- выписывание флешки на 128ГБ для держания под рукой удобного репозитория всех подверсий новых ОС;
- выписывание внешнего/второго жесткого диска для создания клонов акронисом: постоянно приходится откатываться, чтобы в перерабатываемую инструкцию установки-настройки ОС и комплекса вносить минимально необходимую и достаточную информацию - и перепроверяя ее;
- выписывание двух одинаковых мониторов с тонким обрамлением экрана, чтобы строчки исходного кода сливались на них почти воедино без разрывов и смещений. В настоящий момент у меня 2 рабочих места: доработка комплекса на старой ОС и миграция на новом - 4 одинаковых монитора и 1 постоянно крутящаяся башка;
- не дожидаясь ответа заказчика, начать миграцию тех модулей, которые совсем "маленькие" и маловероятные в части внесения изменений в течение 3 лет.

И вот, сама миграция исходников началась. Для примера взяты 3 сделанных за несколько недель самых незначительных модуля: извращенный запускатель модуля самоконтроля, модуль самоконтроля, модуль математической модели определенной поебени.

Проблемой миграции, естественно, оказалось огромное количество ошибок (при условии, что новая инструкция установки-настройки новых ОС, Qt и ГИС уже написана и оттестирована):
- каждый из модулей изобилует десятками и сотнями красных ошибок компиляции. Целью становится не просто запуск и тестирование модуля - его тупо нужно корректно собрать. Вначале ошибочные места просто комментировались, чтобы дойти до определенного состояния "собрался". Это дало плоды во время притирки к процессу миграции;
- если бы формы и ее элементы не создавались динамически, миграция была бы провальна, т.к. их тысячи - и все их пришлось бы пересоздавать со всеми свойствами заново. Это проблема "кроссплатформенности" Qt (к счастью, псих, писавший и ядро, это знал - и учел при миграции с Windows на Linux в далеком 2010-2014 году). По его пути пошел и я, понимая, что рано или поздно наступит миграция-2 - и она наступила именно в мою смену;
- так как существуют одноименные файлы с разными путями - существуют разновидности их выбора и взаимодействия между другими группами таких файлов. При этом создается иллюзия, что пути для них выбраны верно, и у тебя по итогу вот-вот все соберется. И ты добавляешь все новые абсолютные пути к инклудам, а не относительные, - у тебя все меньше красных ошибок, но в окончательном итоге приходишь в тупик. Новые типы ошибок вели не к решению, а к еще большему запутыванию (малое количество нерешаемых проблем). В итоге, родилось понимание, что все INCLUDEPATH в проектных файлах идут лесом - и пишется один-единственный правильный: "/usr/include/x86_64-linux-gnu/qt5". Пример неверного мышления: попытка все сделать на инклудах Qt4/Qt5, в т.ч. и старых инклудах Qt4 проекта (например, "...linux-headers-5.15.0-70/include", "...x86_64-linux-gnu/8/include").

Когда ошибок становится меньше, в дело вступает хаотичность поведения исходников - и каждую минуту может прилетать серьезный именно новый баг, который ты не ожидаешь (о мелких - вообще молчу):
- именно для исходников, взаимодействующих с ГИС (версия «14»: 14.2.6.16 Оператор и 14.3.0.55 Конструктор соответственно), - потребовался пакет, не нужный для самого ГИС (libparsec-mac3-dev). А также добавление еще одного INCLUDEPATH (/usr/include/gisdesigner);
- в проектном файле присутствуют библиотеки, которые не нужны для корректной работы модуля. Естественно: работа с чужими исходниками чревата любыми последствиями - в том числе, излишним "функционалом";
- в общих исходниках (возможно, везде) компилятор не может работать с переменными static ("in-class initializer for static data member of type 'const double' requires 'constexpr' specifier") - приходится убирать это слово (constexpr не помогает). Это приводит к костылям: лишним объектам, содержащим эти static const, - чтобы тупо добраться до значения ("invalid use of non-static data member"). По хорошему, эти константы вообще лучше удалить, и вместо отсылки на них вписать сами числа;
- из-за разницы версий GCC Qt, функции min и max не работают ("macro "min" passed 3 arguments, but takes just 2"). Причем ошибки не в файлах проекта, а в системных, - пока не найдено адекватного решения вопроса, даже при наличии "правильных" ответов в интернете. Неисправленная ошибка не дает возможность ремонтировать модуль дальше - нужно переключаться на другой, держа в голове всю информацию и про этот;
- qmake при сборке и пересборке проектов запускать не нужно. В свою очередь, нужно собирать проект только во второй категории меню "Сборка" (где Ctrl+B): если хоть раз было открыто больше 1 проекта - другие опции сборки вызывают ошибки, ведущие к закрытым проектам. Если же использовать опцию "собрать во всех конфигурациях" при открытом одном проекте - рождается казус: все успешно собирается, бинарник создается - но "cannot open output file ../../../bin/selftest: Permission denied" - и компиляция других модулей (когда весь проект будет собираться) будет остановлена;
- обнаружена несовместимость конкретных 2 проектов: по отдельности собираются нормально, если открыты оба - не собирается ни 1;
- где-то в промежутке между запуском Qt через sudo и запуском Qt не через sudo – очищается буфер обмена ОС, не давая возможность напрямую копировать коды ошибок в инструкцию. Поведение Qt при этом – разное: например, через sudo не видно инклуд QPrinter ("QPrinter: No such file or directory" - при условии, что он там есть, в INCLUDEPATH). Решено неиспользованием sudo для Qt;
- модуль математики был неправильно смигрирован в прошлом - и пришлось исправлять кодировку в 38 файлах на UTF-8 (Qt новой версии блокирует изменение файлов не в UTF-8): Windows-1251, IBM-866 или сразу обе в одном файле. Часть русского текста восстановить не удалось. В main.cpp русский текст потерян навсегда при прошлой миграции;
- несовместимость с функцией gets: она исключена из стандарта C11 - и Qt отказывается ее выполнять (the 'gets' function is dangerous and should not be used). Выражается неинформативной ошибкой "obrabtmn.o: in function `obrabtmn'", описание содержится в желтом восклицательном знаке напротив gets - когда, по логике, знак должен быть красным. Один только поиск проблемы занял 1 рабочий день, полдня из которых шло на рассматривание красных ошибок. Заменена на самописную.

На текущий момент смигрировано не до конца 3 самых малых модуля из 34. Времени, с момента начала изучения новой ОС, - прошло 3.5мес. Смигрированные модули никто не тестировал. 36мес на 34 модуля - это еще оптимистично.

На работу в сектор разработки ПО для изготовления утюгов требуются разработчики и тестировщики с хорошими знаниями Qt. Мы предлагаем: шестизначную зарплату чистыми (шестой знак зависит от количества вдвойне оплачиваемых сверхурочных часов), удобное кресло руководителя, мощный комп с 2 мониторами, адекватное начальство трех уровней, снятие с табеля (свободный вход-выход), командировки в разные города, бронь от мобилизации. Мы требуем: чтобы вы стали моими рабами и делали миграцию за меня - а я просто сидел, делегировал работы, получал зарплату и играл в Fallout. О, я разработал уже существующую парадигму работы некоторых начальников...

Пришло время создать свой сектор...

(добавлено 22.09.2023) Разное:
- миграция осложняется отсутствием интернета - на работе можно подготовить список вопросов, но не получить ответы на них;
- смена версии GCC: 4.7.2 -> 8.3.0;
- буфер обмена ОС очищается именно при выходе из Qt, откуда бы информация в буфер обмена ни помещалась.

(добавлено 25.09.2023) Компилятор ошибочно сообщает о неправильных функциях min-max в h-файлах системы, а на деле - это долбаный ГИС. Еще в 2016 году на их плохо индексируемом форуме поднимался этот вопрос - за 7 лет проблема так и не была устранена. Костыль: #define HIDEMINMAX (или MAXMIN - не помню) перед #include "mapapi.h". При этом, обе этих строки должны идти в конце списка инклудов файла.

Начавшийся мигрировать 4-й модуль добавил еще огоньку:
- отказывается собираться без указания абсолютного пути к устаревшей версии QWebView (с новой версией - получается тонна красных ошибок). При этом еще требуется доустановить пакет libqtwebkit-dev для одного из инклудов QWebView.h. Чтобы узнать название пакета - пришлось из 8 эмпирически подобранных пакетов методом последовательного приближения убирать лишние (постоянно откатываясь акронисом по 1 часу за раз) - предполагая, что пакет может быть нужна не единственный;
- новый ГИС заставляет перетипировать ГИС-переменные в определенные типы. Если раньше вместо HMAP можно было подставить int в функцию - то теперь нет, пиши (HMAP)(int). Изменилась логика работы функции MapCloseMap, не позволяя больше закрывать слои с ее помощью.

Уточнение версии Qt: 5.15.2.

(добавлено 26.09.2023) itoa в stdlib.h больше не существует (нигде не существует). В моем случае, повезло: удалось использовать sprintf(buf, "%d", number) именно для десятичных целочисленных значений.

(добавлено 01.10.2023) Инструкция по настройке ОС и установке мигрируемого ПО для Astra 1.4 занимает 14 страниц - в настоящий момент лишь несколько ее страниц мигрированы на 1.7.4. Случился парадокс: модули невозможно тестировать без наличия SQL, а SQL не устанавливается (застрял, и надолго: материалы старой инструкции не подходят). Также застряло и решение переделки инстиллятора мигрируемого ПО под новую версию postgreSQL.

(добавлено 02.10.2023) Новый неисправимый баг в Astra SE v.1.7.4: не читает диски, официально записанные в машбюро - и дистрибутив программы запущен быть не может. Неважно, астра виновата или машбюро - разборки намечаются нешуточные.

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

Миграция с реального ПК на VmWare v.12.5.6 build 5528349, с использованием Acronis v.2021 build 39287, завершилась провалом. Между тем, образ Acronis успешно восстанавливается на реальном ПК, если нужно откатиться в прошлое именно на этом ПК. Соответственно, идет возня с постоянной перезаписью DVD-RW при отладке инсталлятора - и потеря часа времени на откат акронисом в состояние, инсталлятором не испорченное.

(добавлено 05.10.2023) Еще баги ОС обнаружились:

- на рабочий стол нельзя напрямую вставлять файлы. Через файловый менеджер – удается это сделать;

- сохранившийся за 10 лет: ОС сбивает часы на 3 часа вперед. 1 раз у заказчика часы слетели на 3 часа сами по себе на сервере, без каких-либо манипуляций, - но это касается еще версии 1.4;
- не дает даже под sudo сменить рисунок рабочего стола. После перезагрузки все возвращается обратно. Даже подмена исходного файла изображения на другой не помогает. При этом в виртуальной машине все нормально, а на реальном ПК - нет;

- при выходе из Qt или Kate очищается буфер обмена ОС;
- в сравнении с v.1.6, не запускает sh-файлы с рабочего стола, а также не запускает ярлык терминала с параметром -e "несколько приложений через '|'". Другой человек придумал какое-то извращенное решение этих вопросов - завтра покажет;

- с рабочим столом наблюдается и другой баг: ссылка на HOME не работает с рабочего стола - но без проблем открывается в проводнике. Поэтому ссылку пришлось делать приложением fly-fm.

С миграцией ОС с ПК/ВМ на ПК/ВМ - вышел полный треш, неочевидный (опять UEFI брыкается, как ранее: раз, два, три):

- все ВМ наследуют значение параметра UEFI/Legacy из BIOS (исправлено: в момент создания ВМ, если в настройках ВМ нет опции "EFI/не_EFI");

- миграция из UEFI в Legacy и из Legacy в UEFI, по совокупности экспериментов, - невозможна. Нужно изначально делать выбор, в каком режиме создавать эталонный клон системы для развертывания на пустых ПК/ВМ. Выбрал UEFI: это повод выбить новые ПК после окончания миграции, т.к. часть из них в BIOS вообще не имеет опции UEFI/Legacy - работая в Legacy. Отказ от Legacy планировался в 2017 году, в 2020 Lenovo официально это сделала, в 2023 году вышел официальный документ Intel "Removal of Legacy Boot Support for Intel Platforms";

- структуры физического/виртуального диска с Legacy и UEFI отличаются: в одном есть "MBR", в другом есть "системный раздел" и "дорожка 0";

- ошибка GRUB «error: prohibited by secure boot» решается отключением опции "Secure Boot" в BIOS - то есть, перед установкой ОС требуется еще и в BIOS лезть (она по умолчанию включена).

(добавлено 06.10.2023) Большое начальство предварительно назвало свое видение миграции:
- обязанность вносить изменения в исходники астры v.1.7.4 вручную, если в исходниках астры v.1.4 что-то изменяется. Это нереально, т.к. там постоянно что-то изменяется, - проще повторить весь процесс миграции по написанной инструкции о ней заново по всему измененному за время миграции проекту;
- срок около 8 месяцев. Это нереальный срок для такого гиганта - только если где-то изрядно повезет;
- никто не освобождает меня от доработок по текущему проекту астры v.1.4. Эти 8 месяцев - не настоящие. И как раз заказчик очередную порцию хотелок в понедельник подбросит.

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

(добавлено 07.10.2023) Еще баги подоспели:

- Acronis 2019 года в составе Win PE 11, 10, 8 Strelec v.2023.07.05 не умеет работать с разделами Astra v.1.7.4 в UEFI;
- Acronis True Image v.2021 build 39287 (последняя версия) не работает в UEFI (исправлено: с флешки - и правильное залитие образа исправило ситуацию) – нужно использовать для архивации TeraByte Image for Windows v.3.60 в составе Win PE 11, 10, 8 Strelec v.2023.07.05;
- ни одна из подверсий VirtualBox v.7.0.7.0.10-158379 (bookworm, bullseye, buster) не устанавливаются. VMware v.17.0.0-20800274 устанавливается через sudo - но не запускается, пытаясь установить дополнительные пакеты вида libgcc-s1, libvpx*, - отсутствующие и на установочном диске, и в обоих репозиториях. Надеюсь, все обойдется одним скачанным со стороннего ресурса пакетом libvpx5_1.7.0-3+deb10u2_amd64.deb;

- md5sum /dev/sr0 врет при расчете контрольной суммы, если носитель CD-RW записан встроенными средствами Windows 7 (т.е., некорректно и отформатирован, и финализирован при записи);

- МФУ Canon MF4410 не имеет драйвера и не работает с предполагаемыми заменителями.

(добавлено 09.10.2023) С виртуальными машинами ситуация попроще - но только на примере VirtualBox в Linux. VirtualBox v.7.0_7.0.10-158379 "Buster" успешно заработала в Astra Linux SE v.1.7.4, с использованием стороннего пакета libvpx5 (libvpx5_1.7.0-3+deb10u2_amd64.deb) - потребовав еще 5 дополнительных пакетов из репозитория (они созависимы - достаточно двух: build-essential, libsdl-ttf2.0-0). Она имеет в себе опцию Системы "Включить EFI". В итоге, при смене режима Legacy на UEFI в материнской плате, виртуальные машины с Legacy будут работать нормально.

Однако когда в 2024 году поддержка Legacy полностью окончится (Removal of Legacy boot support for Intel platforms. Technical advisory WW31, August 2023. Document number: 630266 стр.5), и Legacy уйдет из материнских плат аппаратно, - поведение виртуальных машин с Legacy непредсказуемо. В связи с этим, нужно до 2024 года заменить в секторе максимальное количество компьютеров на новые, чтобы поддержка обоих режимов физически продержалась как можно дольше (Astra Linux SE v.1.4 не дружит с UEFI).

О багах:
- с дисками машбюро: не открываются именно на старых DVD-приводах старше 2008 года включительно - и решается только заменой DVD-привода;
- в файле Release в установочном компакт-диске ОС заявленная версия - 1.7.4, но по факту в ярлыке "информация о системе" - 1.7.4.7. Еще бы день не была бы известна эта информация - и письмо к заказчику с требованием придерживаться определенной версии ОС с точностью до 4 знака версии ушло бы с неверным числом билда!

Исправление собственной ошибки. Разработчики астры не виноваты, что их установщик "не грузится" с флешки в UEFI: вина программы-создателя/заливателя образа диска/флешки.

(добавлено 14.10.2023) В связи с нахождением успешного способа инсталляции обеих Astra Linux SE с флешки, можно начать операцию по отказу отдела от DVD-приводов.

По МФУ Canon MF4410: драйверы производителя доступны только при принудительном выборе опции английского языка - что немного намекает на русофобию.

Еще баги астры:
- встроенный архиватор хорошо открывает архивы 7-Zip только до версии 19. Версию 23.01 с максимальной компрессией уже не берет;
- вероятность монтирования и открытия флешки с файловой системой FAT32 – не 100%;
- нельзя создавать папки с постфиксом «.tar» в имени (например, распаковка архивов архиватором). Менеджер файлов начинает глючить: циклический переход в корень папки tar – думая, что переходит глубже.

(добавлено 15.10.2023) Еще баги астры:
- если какой-либо раздел, прописанный вручную в fstab, исчезает (вынут/уничтожен) – ОС перестает загружаться (на примере флешки - прописал в попытке устранить баг "когда флешка воткнута - не монтируется, пока не перевоткнешь"). Если ОС накатить на точно такой же ПК - вставка недостающей флешки в идентичный разъем проблему "устраняет";
- VirtualBox не видит ни одну вставленную флешку. Та же версия под Windows все прекрасно видит.

(добавлено 17.10.2023) Миграция большой SQL-базы добавляет остроты.

(добавлено 18.10.2023) Qpdfview теперь называется Okular, juffed – Kate. Как следствие - в уже скомпилированных исходниках не работают кнопки с упоминанием старых названий.

Карты ГИС 11 оказались несовместимы с ГИС 14 - что с этим делать, пока непонятно. Сам же ГИС глючит нещадно. Указываешь файл map_obj.mtw вместо map.mtw - он спросит: "Перезаписать map_obj.mtw?" - и перезаписывает map.mtw...

(добавлено 19.10.2023) Заказчик прислал факс с требованием поставить уже смигрированный комплекс в феврале - то есть, на миграцию есть всего 3-4 месяца. Они там все е*анулись, похоже...

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

(добавлено 21.10.2023) Началась миграция с ГИС 11 на ГИС 14, со старых карт на новые (не поддерживаются), со старых команд на новые. Несмотря на то, что руководство программиста содержит идентичные названия функций, - в реальности функции ГИС 11 вынесены в файл "mapapiold.h", в новой ОС и новом ГИС - на текущий момент не функционируют. И возникает простой вопрос: какая же замена у устаревшей mapOpenMap, если h-файл "old"? Лезешь в руководство программиста - а про нее там вообще ни слова. И никогда и не было: в руководстве от настоящего 2014 года - тоже ни слова.

Багов - тонна, на форуме ГИС ничего толкового нет. Например, перед каждым открытием карты требуется функция QDMapView, отвязывающая карты от ключа ГИС-Оператор. И это при условии, что эта функция упоминается в руководстве системного программиста как "компонент управления электронной картой" - и про отвязку от USB-ключа вообще ни слова.

Придется прекращать обновлять этот материал. И сроки резко сократились до невозможных, и описывать все возникающие баги (одна миграция БД SQL чего стоила) - простыня получится. Напоследок хочется сказать еще о ГИС. Мало того, что в их руководстве от 2023 года стоит дата 2014 год (прямо на лицевом листе) - так за эти 10 лет они даже кодировку в файлах своих функций не поправили. Так традиционно открываются h-файлы в Qt под Linux.

И еще напоследок - еще один баг астры: программа Gwenview, открывающая несколько jpg-рисунков сразу, глючит при печати: открыто и автоматически выделено несколько рисунков - но печать происходит только последнего.

(добавлено 23.10.2023) Всё, заболел - приехали.

(добавлено 01.12.2023) Заболевание, в измотанном состоянии из-за миграции, привело к серьезным последствиям и решениям:

- аналог сердечного приступа;

- решение уволиться с работы и трансформирование этого решения;

- к данным ПО и заказчикам больше никогда не буду иметь никакого отношения. Либо переведусь в другой отдел, либо найду-таки способ заниматься в текущем чем-то другим;

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

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

- срок миграции диктует разработчик, тройной;

- разработчик имеет доступ к неограниченному количеству помощников.

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

(добавлено 27.05.2024) Спустя полгода после отказа от программирования, в связи с порчей здоровья из-за этого, - решил переделать домашний проект из кода на VB6 в код на Qt v.5.5.1 для Windows (повысить удобность интерфейса, выйти за пределы 2ГБ при создании файлов). Знатно стошнило - буду писать в BCB6 в виртуалке с Windows 7 (в Windows 10 он уже не работает - хотя создаваемые им дистрибутивы работают). Qt - реальное говно, а не среда программирования.