Смотря для чего тяжелый. В нашем случае такой размер устраивал и я не стал возиться с триммингом. FPS при прямом рендеринге на глаз лучше чем на этой же железке в оконном режиме, но я не замерял его. Мне кажется, ниша Авалонии в ембедед системах где то между тяжелым браузером и Qt который позволяет выжать из железа все.
Это большая сложная тема. Понятно, что еще не весь софт перевели на Linux, поэтому миграцию нужно правильно планировать. Кого-то может на Windows будет дешевле оставить. Но на Wine я бы не полагался. MS никогда не давали разработчикам Wine официальных спеков. У этого проекта очень ограниченная область применения.
Вы поняли неправильно. Я говорил не про отличия линуксов, а про отличия подходов к разработке. Если полагаться на вайн, то путь разработки будет примерно такой: делаем ПО под Windows, потом проверяем что оно работает под Wine. Это примерно то же самое что ездить на велосипеде чтобы выиграть марафон по бегу. Не стоит так делать. Если хотите поддержать линукс - поддерживайте. Есть прямой честный путь. Без шапкозакидательства.
Дело ведь не только в бумажках. Стратегически неправильно строить серьезный софт на ненадежном фундаменте. Вайн - хоршая штука чтобы получить дешево что то из экосистемы windows на linux. И у него есть своя ниша - игрушки. Очень сомневаюсь что кто то будет смотреть в сторону вайна, если в договоре на поставку его софта будет прописана хоть какая то ответственность.
В лучшем случае вы научите уже выпущенный софт как то работать. Как то. Но каждый день производится новый софт и никто не тестирует его в вашем окружении. Именно в этом проблема всяких "вайнов" и "водок". Чтобы софт работал на российской операционной системе надо чтобы в CI были тесты на совместимость с ней. Вот, несколько лет назад мы наблюдали появление своих процессоров у Apple. Представляете сколько всего им надо было сделать чтобы под m1 появился качественный софт... Но они почему то не пошли по пути который вы предлагаете.
Да, с физическими уствойствами вариантов нет, нужно их эмулировать в тестах. Мне довелось поработать в одном интересном проекте. Мы делали софт для томографа. Для тестов там был сделан эмулятор реального устройства который выдавал мегабайты случайного шума вместо настоящих снимков.
Получается, вы тоже пришли к тому, чтобы прятать сложность взаимодействия с UI в отдельные классы. Мы тоже подменяем части системы при тестировании используя DI. Но тут может возникнуть вопрос: а не произошло ли подмены тестируемого объекта ). У нас есть отдельная категория e2e тестов в которй почти ничего не подменяется. Цель таких тестов - проверить основные сценарии работы системы в окружении максимально приближенном к пользовательскому окружению. Мы их называем тесты последней надежды или install тесты. Они работают на бинарниках которые устанавливает инсталлер. Как нибудь расскажу в деталях.
да, спасибо, посмотрим, может быть будет какой то официальный документ с пояснениями как они будут применять этот закон и самое главное как контроллировать его исполнение.
Столько вопросов.. Какие именно сайты должны это выполнять те что в ru зоне? Как определять что у пользвателя почта не такая как надо? Как это будут контроллировать? Контрольной регистрацией? А если пользователь в логине указал гуглопочту, но не использует вход ченез гугл?
Спасибо, что обратили внимание. Мы проверим этот момент с коллегами.
Я для устранения дефектов распознавания использую собственную (неопубликованную) программу «МедиаГекст».
Скриншоты выглядят отлично. Видно, что проделана большая работа.
Если не считать непонятную задержку при рендеринге фрагментов статей в HTML-формате. Это проблемы сервера?
В статье я говорил про затраты времени на приготовление всего сайта. Имеем на входе набор XML-файлов Help&Manual, а на выходе должен получиться сайт. Этот процесс состоит из нескольких стадий (как я это понимаю):
XSLT-преобразование XML → MD.
MkDocs / Zensical готовят из большого набора MD-файлов HTML-файлы с учётом заданных стилей и шаблонов, добавляется код Яндекс.Метрики в каждую страницу.
Кроме собственно контента сайта в виде HTML, надо правильно приготовить навигационную часть сайта (то, что будет показываться в левой колонке).
Есть ещё стадия приготовления индекса для полноценного поиска по сайту.
Все эти стадии требуют полного обхода содержимого статей, и поэтому сборка сайта занимает некоторое время, если у вас приличное количество материала.
У портала документации действительно прописаны некоторые ограничения на использование материалов (https://docs.eremex.ru/legal/). Я не юрист и не могу их комментировать. Если у вас есть идея, относящаяся к нашим статьям, напишите нам. Я уверен, всё можно решить.
Все наши статьи в исходном виде хранятся в XML-файлах Help&Manual, поэтому нам не пришлось возиться с извлечением информации из PDF-файлов. В общем случае это очень сложная задача. Мне встречались PDF-файлы, в которых текст был представлен в виде растрового изображения. Также в некоторых случаях текст в PDF может быть преобразован в набор кривых. Поэтому в общем случае извлечение контента из PDF — это сложная задача, сравнимая по сложности с распознаванием документа. Хорошо, что нам не пришлось этим заниматься.
Flatpak - более новая и продвинутая система. Она имеет полноценную песочницу у которой можно настроить права и окружение. Есть централизованный хаб для прилоожений, поддерживаются автоматические обновления. Флетпак лучше интегрируется в систему: иконки, нотификации, персистные хранилища. У Flatpak есть явная стадия установки на систему пользователя.
AppImage это по сути способ запаковать приложение и все его зависимости в один исполняемый файл. Для наших САПР этого недостаточно.
Смотря для чего тяжелый. В нашем случае такой размер устраивал и я не стал возиться с триммингом. FPS при прямом рендеринге на глаз лучше чем на этой же железке в оконном режиме, но я не замерял его. Мне кажется, ниша Авалонии в ембедед системах где то между тяжелым браузером и Qt который позволяет выжать из железа все.
Это большая сложная тема. Понятно, что еще не весь софт перевели на Linux, поэтому миграцию нужно правильно планировать. Кого-то может на Windows будет дешевле оставить. Но на Wine я бы не полагался. MS никогда не давали разработчикам Wine официальных спеков. У этого проекта очень ограниченная область применения.
Вы поняли неправильно. Я говорил не про отличия линуксов, а про отличия подходов к разработке. Если полагаться на вайн, то путь разработки будет примерно такой: делаем ПО под Windows, потом проверяем что оно работает под Wine. Это примерно то же самое что ездить на велосипеде чтобы выиграть марафон по бегу. Не стоит так делать. Если хотите поддержать линукс - поддерживайте. Есть прямой честный путь. Без шапкозакидательства.
Дело ведь не только в бумажках. Стратегически неправильно строить серьезный софт на ненадежном фундаменте. Вайн - хоршая штука чтобы получить дешево что то из экосистемы windows на linux. И у него есть своя ниша - игрушки. Очень сомневаюсь что кто то будет смотреть в сторону вайна, если в договоре на поставку его софта будет прописана хоть какая то ответственность.
Сейчас вайн версия неактуальна. У Компаса есть официальная линукс версия.
Промышленный и тем более медицинский софт так не делают. За вайн и водку в этой сфере могут и посадить ведь от этого софта зависит жизнь людей.
В лучшем случае вы научите уже выпущенный софт как то работать. Как то. Но каждый день производится новый софт и никто не тестирует его в вашем окружении. Именно в этом проблема всяких "вайнов" и "водок". Чтобы софт работал на российской операционной системе надо чтобы в CI были тесты на совместимость с ней. Вот, несколько лет назад мы наблюдали появление своих процессоров у Apple. Представляете сколько всего им надо было сделать чтобы под m1 появился качественный софт... Но они почему то не пошли по пути который вы предлагаете.
Да, с физическими уствойствами вариантов нет, нужно их эмулировать в тестах. Мне довелось поработать в одном интересном проекте. Мы делали софт для томографа. Для тестов там был сделан эмулятор реального устройства который выдавал мегабайты случайного шума вместо настоящих снимков.
Получается, вы тоже пришли к тому, чтобы прятать сложность взаимодействия с UI в отдельные классы. Мы тоже подменяем части системы при тестировании используя DI. Но тут может возникнуть вопрос: а не произошло ли подмены тестируемого объекта ). У нас есть отдельная категория e2e тестов в которй почти ничего не подменяется. Цель таких тестов - проверить основные сценарии работы системы в окружении максимально приближенном к пользовательскому окружению. Мы их называем тесты последней надежды или install тесты. Они работают на бинарниках которые устанавливает инсталлер. Как нибудь расскажу в деталях.
Нормальное название. Состоит из проф терминов. Переводить их на русский - плохая затея.
Идея красивая. На каком вы сейчас этапе? Есть ли внедрения у Plumix? Есть ли hot reload?
Идея шикарная, но я не дождался загрузки уровня )
Да, вы правы, плавающая версия несовместима с централизованным упралением версиями. Надо было мне уточнить этот момент.
да, спасибо, посмотрим, может быть будет какой то официальный документ с пояснениями как они будут применять этот закон и самое главное как контроллировать его исполнение.
Столько вопросов.. Какие именно сайты должны это выполнять те что в ru зоне? Как определять что у пользвателя почта не такая как надо? Как это будут контроллировать? Контрольной регистрацией? А если пользователь в логине указал гуглопочту, но не использует вход ченез гугл?
Какую именно проблему нужно решить? Вы хотите портал с нашей документацией разместить в закрытой сети предприятия?
Спасибо, что обратили внимание. Мы проверим этот момент с коллегами.
Скриншоты выглядят отлично. Видно, что проделана большая работа.
В статье я говорил про затраты времени на приготовление всего сайта. Имеем на входе набор XML-файлов Help&Manual, а на выходе должен получиться сайт. Этот процесс состоит из нескольких стадий (как я это понимаю):
XSLT-преобразование XML → MD.
MkDocs / Zensical готовят из большого набора MD-файлов HTML-файлы с учётом заданных стилей и шаблонов, добавляется код Яндекс.Метрики в каждую страницу.
Кроме собственно контента сайта в виде HTML, надо правильно приготовить навигационную часть сайта (то, что будет показываться в левой колонке).
Есть ещё стадия приготовления индекса для полноценного поиска по сайту.
Все эти стадии требуют полного обхода содержимого статей, и поэтому сборка сайта занимает некоторое время, если у вас приличное количество материала.
У портала документации действительно прописаны некоторые ограничения на использование материалов (https://docs.eremex.ru/legal/). Я не юрист и не могу их комментировать. Если у вас есть идея, относящаяся к нашим статьям, напишите нам. Я уверен, всё можно решить.
Все наши статьи в исходном виде хранятся в XML-файлах Help&Manual, поэтому нам не пришлось возиться с извлечением информации из PDF-файлов. В общем случае это очень сложная задача. Мне встречались PDF-файлы, в которых текст был представлен в виде растрового изображения. Также в некоторых случаях текст в PDF может быть преобразован в набор кривых. Поэтому в общем случае извлечение контента из PDF — это сложная задача, сравнимая по сложности с распознаванием документа. Хорошо, что нам не пришлось этим заниматься.
Flatpak - более новая и продвинутая система. Она имеет полноценную песочницу у которой можно настроить права и окружение. Есть централизованный хаб для прилоожений, поддерживаются автоматические обновления. Флетпак лучше интегрируется в систему: иконки, нотификации, персистные хранилища. У Flatpak есть явная стадия установки на систему пользователя.
AppImage это по сути способ запаковать приложение и все его зависимости в один исполняемый файл. Для наших САПР этого недостаточно.
Я специально пропустил этот аспект потому что мы еще не выкладывали DDHome на Flathub. Как опубликуем - напишу еще одну статью )