Comments 117
На днях GIMP праздновал, что перешёл на GTK3. А в прошлом году уже забыл кто торжественно объявил, что они переходят на Python 3.
У меня как-то была проблема с тем, что собранный в одной версии Убунты (AMD64) пакет не работал в другой (так же AMD64, но поновее на один или два релиза), потому что версии GLIBC были разные.
То есть вы собирали в более старой системе, а на более новой код не работал? Интересно, что именно такой метод предлагается в статье (собирать на старом дебиане).
Теоретически, glibc очень неплохо совместим вверх.
скорее было наоборот, я собирал на относительно новой десктопной (ноутбочной) Убунте, а ставил на LTS-почти-EOL на сервере.
@Sap_ru FYI
лучше собирать на максимально старой системе, ну как: главное glibc постарше. Я использовал Holy Build Box.
У ELF-файлов есть возможность поддерживать различные таблицы экспорта для различных версий API. И потом при линковке указывать необходимую версию, которая будет выбираться рантайм при связывании загружаемых библиотек.
Сильно геморно и никто этим особенно не заморачивается, но glibc заморачивается. В результате glibc вполне неплохо умеет эмулировать старые версии API самого себя - там по несколько вариантов реализации некоторых функций прописано.
И даже можно имея новую версию glibc скомпилироваться и слинковаться для старой версии glibc. Проблемы будут только с компилятором, который будет требовать наличия свежих имплементаций служебных функций. Но если взять более старый компилятор и накрутить пару флагов, то всё получается.
Собственно, glibc одна из немногих библиотек, которые реально используют фичу с различными версиями API в одной библиотеке. Кроме них только пара-тройка низкоуровных системных библиотек так заморачивается, а все остальные тупо добавляют версию в имя библиотеки и не парятся.
Забавно, что винде настолько плевать на действия юзера, что я поменял компьютер полностью, оставив только жесткий диск. Она даже не подавилась. А по существу - да, нагромождение абстракций в айти повсеместно и никак не помогает)
это вам как то сильно повезло, обычно как раз с этим проще у линукса. Хотя сильно повысить шансы завести Windows на новом железе можно при помощи sysprep
Переезжал, если что, с intel pentium из "новых", не помню индекс, на рязань 3600
Процессор там не самое страшное. Обломы чаще возникают из-за экзотических контроллеров жестких дисков (всякие странные SATA, RAID и т.п), что может привести к тому, что система не сможет найти диск для загрузки.
Если переезд плановый, обычно это не проблема - драйвера контроллеров как правило можно сбросить на стандартные/добавить целевые как на онлайн винде, так и на оффлайн (с помощью инструментов с live cd).
UEFI уже давно решает эти проблемы, когда загрузчик ищется прошивкой на любом диске, отформатированном в FAT и имеющим конвенциональные пути. Остаётся только подсунуть загрузочные драйверы для особо нестандартных систем (при том, что большая часть обычных есть в стоке).
У меня за 12 лет Windows пережила два полных апгрейда компа (включая миграции загрузочного диска SATA -> SSD SATA -> SSD NVMe) и все апгрейды самой ОС от Win 7 до Win 11. И всё без переустановки.
У меня как-то был жёсткий диск, который пережил смену двух процессоров интел, смену платформы на амд, клонирование на м2, затем смена процессора, затем клонирование и накатывание на ноутбук с интел.
В Win10/11 с этим стало значительно проще. Вот во времена WinXP/7 смена чипсета с сопутствующими драйверами дисковой подсистемы могла превратиться в увлекательное путешествие, если заранее дисковые драйвера на базовые не сбросить.
C windows XP-vista всё было легко решить заранее, в установщике windows (через shift+f10) сохранив профиль оборудования ещё до того, как все эти драйвера поставились.
Тогда при переезде на другую машину достаточно было выбратть этот сохранённый профиль. Если у системы несовместимый процессор - ещё добавить опцию загрузки нужного варианта ntoskrnl.
В windows 7 всё это поломали - теперь профилей оборудования нет. Это кстати для меня была основная причина ухода с windows - в XP я прекрасно мог использовать одну инсталляцию на нескольких разных ситемах (в том числе виртуалке), в семёрке это перестало работать. Десятка конечно грузится на разных конфигурациях - но со скрипом. К сожалению ей нельзя подсказать мол это другое железо и грузи другой профиль - она будет весь его перелопачивать.
В линуксах хоть штатного механизма что-то такое сделать нет, но можно установитть 2 разных ядра под разные конфигурации и в инитскриптах сколхозить проверку по cmdline, меня енвы в зависимости от того, какое из ядер загружено, таким образом, например, выбрав использование mesa или блоба nvidia.
Это с семёркой в этом плане был геморрой. А десятка просто откатывается на дефолтные дрова и запускается, даже если ничего не делать предварительно.
Зато если что-то пойдет серьезно не так - проще под переустановку. Linux проще вылечить (другое дело что могут какие нибудь странности про не уход в сон или не работе микшера появится...на конкретном железе с конкретным софтом)
Linux проще вылечить
Как раз наоборот. Линукс проще переустановить. Диагностика "что пошло не так" в упавшем Linux отвратительная.
А в Windows?) ну кроме простых случаев когда переставить дрова или софт
Как раз наоборот
Все же как раз наоборот)) Ладно, прошу не продолжать холивар
(Поперхнулся чаем и полез коментрировать) Я не знаю какой Linux вы поднимали, но обычно там диагностика в тыщу раз лучше, чем в винде.
У меня совсем другой опыт.
И средств для разбора полетов больше и они удобнее. Да - в Windows тоже логи но скажем так работать с ними существенно сложнее а искать осмысленное - еще сложнее но например если творится какая то фигня - у менять есть шансы и посмотреть что вообще приложение делает и повлиять и это штатным средствами, у Windows - Regmon/Filemon и прочие TCPView - от типа независимых товарищей Sysinternals.
Случаев что под Linux критичная для меня проблема в принципе не решается никак (не путать что путь решения вообщем то понятен но править кучу код - сил нет) - у меня не было, в отличии от Windows (из недавнего утилитка HTTP toolkit + Docker Desktop - или одно будет работать или другое, вместе - нет, причем диагностика будет максимально невнятная, и похоже реальная проблема - WSL2(которую Docker Desktop использует) - как то хитро с сетью работает).
Кстати вот издевательства над пользователем при апгрейдах тоже не очень то помню под Linux (в том числе и потому что если авторам gnome моча в голову ударила - есть KDE, да много что есть, включая MATE), а в Windows - например StartIsAll теперь у меня обязательный к установке, после установки на другое железо/виртуалку каждый приходится разбираться куда на этот раз засунули отключение "очень важных предложений". Да хотябы весьма агрессивное впаривание MS Account чего стоит.
У нас для тестов на работе есть куча всяческих материнок интел и амд, между ними таскаются диски с операционками. Так проблем с 10кой нет. Она везде стартует.
Начиная с десятки там сильно подкрутили в плане возможности миграции. Если на новой системе контроллер дисков не требует особенных драйверов, которые нужно подсунуть при установке, то, скорее всего, переезд пройдет нормально. Хотя другие экзотические устройства тоже могут огорчить BSODом, если драйвера в системе правильного нет. Видеокарта может "обидеться" на "слишеом старый" или "млишком новый" драйвер вплоть до BSOD.
Статья на тему "как не давать исходники" ⇒ не_нужна.
а вы из тех, кто готов терпеть и пересобирать проект уровня браузера или либреофиса из-за того, что его авторы не успели/не захотели сделать билд под какой-нить обскурный VibeLinux?
какбе опенсорс и нормальное аби - перпендикулярные вещи; более того - еще и ядро можно писать так, что у тебя загружаемые модули будут подходить не только к конкретной VERMAGIC, а к разным релизам вообще.
Мир знает ОС когда драйвера можно было использовать вообще собранные под другую архитектуру (PowerPC --> Intel, к примеру).
Если вы про Apple, то эта традиция продолжается. Буквально на днях на arm-макбук накатил x86-драйвера на принтер, все работает без проблем.
дубль
Драйвера принтера, слава богу, везде не являются чем-то системным. Скорее всего там обычный CUPS (поддержкой которого яблоко и занимается).
Несколько месяцев назад пытался запустить 4G свисток от Хуавея на Macbook M, не получилось. Увидело как накопитель, увидело файл, но запустить не смогло, сказало не для него оно.
Это нормально, у модемов обычно два режима работы в одном они определяются как диск на котором записаны драйвера и утилита для управления, а во втором они определяются как сетевой адаптер и работает на драйвера из ОС, которые уже везде есть, но теряется управление типа доступа к смс.
обычно там не сетевой адаптер, а serial порт. К тому же откуда у диска доступ к СМС?
Я про то что есть универсальный режим поддерживающий ndis и работающий из коробки в любой современной ОС. А во втором режиме требуются специализированные драйвер и утилита для управления, которая инициирует старт и остановку сессии, позволяет читать смс, отправлять USSD команды и прочее. Обычно это разные прошивки.
У мейнтейнеров VibeLinux что никто не занят либреофисом тем же и даже билд-фермы к которой можно попросить доступ чтобы собрать? Если при этом оный VibeLinux я использую (видимо что то там для меня очень важное) - я в такой ситуации попрошусь в мейнтейнеры либреофиса в VibeLinux и буду собирать (уж найду ресурсы)
К сожалению не только. Совсем не факт что даже из старых исходников все соберется (да пример в приведенном ж у них скрипте с ставим один компилятор конкретной версии, им собираем другой, которым уже собираем что надо). Надо переписывать софт. Весь включая написанные годы назад утилиты где разработчику не до них.
Внезапно вспоминается...Pinokio (который https://pinokio.computer/) - по сути что-то вроде юзер-френдли установщика софта для около-ии-задач. Под Win/mac/linux. Почти весь этот софт - на питоне+немного на C с биндингами в питон и лежит на гитхабе. Но - требуются конкретных версий зависимостей (у разных софтин - разных версий, причем на неправильных может работать...не совсем корректно), желательно - с избеганием дублирования хотя бы файлов моделей а лучше и кода и так далее. Казалось бы - почему бы людям просто не взять и не писать совместимое с собой же...а вот не выходит. Есть конечно докер...но тут это тоже не очень хорошее решение (оверхед например)
Если класть болт на коммерческий софт - линукс на десктопе точно никогда не взлетит.
а если заставлять разработчиков того же опенсорса каждые полгода переписывать пол-кода из-за того, что в тулките или библиотеке решили поменять порядок аргументов и перекрасить кнопку, то и с открытым софтом всё так и будет тяжко. потому что кто и когда будет "бизнес-логику" отлаживать, если всё время на борьбу с СДВГшными авторами уходит?
Я, как разработчик небольшого количества опенсурс софта и библиотек, понимаю боль обратной совместимости. Часто нужно добавлять фичи, что-то улучшать, при этом бэкпортируя фиксы в прошлые стабильные версии (по semver). Это большой труд и многие на него не идут.
Но, если это достаточно большой проект, от которого многие зависят - тут приходится уже идти на эти жертвы. В идеале - иметь LTS ветки, в которых нет ломающих изменений и бэкпортируются только фиксы в течении Х лет. Но таких проектов - по пальцам пересчитать...
На тему "сборка из исходников" можно ещё статью написать. Тут тоже много нюансов, связанная с компиляторами, их версиями и стандартами.
Линковка с библиотеками дистрибутива таит в себе подводный камень в виде патчей от мейнтейнеров дистрибутива, которые могут заставлять библиотеку с версией x.y.z работать почти так же, как в другом дистрибутиве, но не совсем...
JVM - наше все :)
В геймдеве примеров тяжёлых jvm-игр с доступом к Vulkan, VDPAU, CUDA и нет. Какой тайтл не возьми, там будет что-то типа UE4/UE5/CryEngine/Unity.
Minecraft: Я для вас что, какая-то шутка? (Ладно-ладно, Vulkan там модом только. Но есть же. :)
Что сильно удивляет, кстати. Но справедливости ради, там были объективные причины - очень медленный доступ к низкоуровневым массивам, медленный обмен данными с драйверами/подпроцессами и проблемы с примитивными типами.
Сейчас это всё, кстати, решили и теоретически на последней JVM вполне можно быстро работать со всякими текстурами и прочими двоичными данными. Даже векторную математику начали подвозить. Так что объективных проблем больше нет. Но может оказаться, что поезд ушел и больше просто нет интереса.
Будем наблюдать,
Там, кстати, заодно порешали практически все сложности со взаимодействием с ИИ-железом, и сейчас JVM выглядит на 10 голов лучше Python для всяких ИИ-экспериментов, но нужны инвестиции.
Так что объективных проблем больше нет.
GC и повышенный расход памяти из-за рантайм информации по объектам.
У китайцев есть свой форк jvm где они этм проблемы порешали. Жаль не выкладывают наработки в опенсорс.
Новые версии JVM уже всё это порешали. Причём именно основываясь на опыте китайцев. Из принципиального осталось улучшить поддержку наследования примитивных типов и избавиться от boxing/unboxing. И тестовых фичах это даже уже есть и работает, но там сложные вопросы с обратной совместимостью и с языками, использующими JVM, так процесс займёт некоторое время.
А остальное уже вполне себе сделано не хуже, чем у всех остальных.
Мм. Выпускать софт вместе с системой целиком.
Выпускать софт вместе с системой целиком.
где нужна гарантированная стабильность, так часто и делается. Примеры: F5 BIG IP LTM, Checkpoint разные firewalls, другие appliances, ESXi ..
Для игр подход выглядел бы весело. Захотел поиграть - переустанови ось (и железо) )
Где-то раньше такое было.. Картриджи для Dendy ?
где нужна гарантированная стабильность, так часто и делается. Примеры: F5 BIG IP LTM, Checkpoint разные firewalls, другие appliances, ESXi ..
Тут выплывает другая сторона медали - когда добро в этих ОС собрано с какими-то древними дырявыми библиотеками, которые никто никогда не патчит. В итоге ты зависишь от вендора софта, а не от ОС (которая в среднем живёт дольше софта вендора), в вопросе закрытия уязвимостей...
Тут выплывает другая сторона медали - когда добро в этих ОС собрано с какими-то древними дырявыми библиотеками, которые никто никогда не патчит.
Вот неизвестно что хуже. Когда так, или когда разработчики дистрибутива какую-нибудь уязвимость в библиотеке давно запатчили, но приложение, которое притащило все с собой, так и пользуется какой-то уязвимой древностью.
Подтвержу, переносимость исполняемых файлов под GNU/Linux - это боль. Программа, собранная под более новой версией Ubuntu не работает на более старой из-за несовместимости glibc. Не понятно при этом, почему нету возможности при сборке компилятору как-то указать, что не надо использовать новый функционал этой библиотеки, кроме как ставить как-то отдельно более старую версию самостоятельно.
Под Windows это сделано гораздо лучше. Я из под Windows 10 с помощью Visual Studio 2019 собирал исполняемый файлы для WIndows XP и они работали без всяких нареканий.
Обычно такой софт приходится таскать вместе с рантаймом. Исключение - какой нибудь старый dotnet 4 или ниже.
Пробуешь запустить софт, собранный 5, 6, 7 дотнетом на десятке, что происходит?
Ну тут несколько вариантов. Первый - вообще ничего. На запуск exe никак не реагирует.
Второй - появляется мессажбокс, мол надо установить дотнет с кнопкой ok, которая ничего не делает. Даже версию дотнета не пишет. Под wine почему-то эта кнопка ok запускает браузер со ссылкой на нужный дотнет, но под десяткой ничего не происходит.
Вот и приходится вместо 100кб приложения делать 100мб self-contained.
Что в linux в терминале, что в windows в мессажбоксе обычно видно, какой зависимости не хватает. Да, отсутствие мессажбокса при запуске ярлыка в linux это отдельная давняя проблема и никто её не пытается решить.
А вот в случае с дотнетом тут одновременно сработало несколько багов (ещё раз отмечу, что под wine после нажатия кнопки ok открывается браузер со ссылкой на нужный дотнет, но под windows это сломано)
Первый баг: если установлен хоть какой-то dotnet sdk - мессажбокс не появляется. Может microsoft предполагали, что если пользователь уже установил sdk, ему не нужен мессажбокс и он сам посмотрит что это за ассембли и поставит? Но на деле конечно же sdk обычно поставлен кем-то автоматически и пользователь о нём не в курсе.
Второй баг - когда мессажбокс появляется, но кнопка ок ничего не делает. Видимо, воимя какой-то безопасности windows блокирует открытие браузера. Или это из-за политики принудительного навязвания microsoft edge пользователю. В любом случае, это происходит на чистой windows, подключённой к домену. На windows без домена не проверял - но тут проблема очевидна, разрабочтки винды не согласовали свои же продукты между собой, сам по себе браузер на этой windows работает.
На самом деле если бы мессажбокс указывал требуемую версию - проблема была бы несущественна. Но он пишет просто мол установите дотнет, а этих дотнетов уже пруд пруди.
Да, наверно с aot ситуация была бы лучше, но когда проблема для меня была актуально .net7 ещё только появился и код писался под 5 и 6. Так же .net7 вроде как (если я не ошибаюсь) установлен в windows 11 по дефолту и всё выше шансы, что он будет уже установлен в системе даже на десятке
Касательно же отдельного лончера - может это и решение, но у лончера тоже есть какие-то зависимост и если я пишу на кроссплатформенном дотнете, то мне не хотелось бы обвязвать его платформенными лончерами. Так или иначе, в exe файле, запускающем дотнет уже есть механизм, показывающий этот мессажбокс и открывающий браузер. Просто оно не работает из-за вышеописанных багов
Не понятно при этом, почему нету возможности при сборке компилятору как-то указать, что не надо использовать новый функционал этой библиотеки
Есть такой флаг. -Wl,--version-script. Сходите в ChatGPT за примером использования
Мне кажется вообще всё устройство GNU/Linux выше уровня ядра в некоторой мере порочной. В нём нету нормального разделения на пользовательское и системное ПО. Вполне нормальным считается, что авторы дистрибутива собирают сами всё доступное ПО из исходников и кладут его в свои репозитории, откуда его предполагается устанавливать. Если его там нету или версии там не очень свежие, пользователь должен выполнять нетривиальные действия по его установке, которые часто могут увенчаться неудачей, ибо или версии системных зависимостей не те, или ещё что-то не так.
Windows в этом плане работает гораздо лучше. Там системными считаются только ряд базовых библиотек (вроде kernel32.dll), которые стабильны, насколько это возможно (вплоть до багов). Все остальные зависимости автор прикладного ПО волен получать как ему вздумается.
Некоторые могут тут заявить, что дескать зависимости могут дублироваться, если более чем одна программа их использует, и что это съедает место на носителе. Но я не вижу нынче в этом проблемы - библиотеки весят относительно немного, а носители сейчас большие (не несколько сот мегабайт, как в 90-е). К тому же такой подход гарантирует стабильность ПО, т. к. авторы каждой программы тестируют её ровно с теми версиями зависимостей, что они используют, а не с тем, что там может на пользовательских машинах стоять.
если более чем одна программа их использует, и что это съедает место на носителе.
Не только на носителе. В памяти. Разделяемая библиотека загружается один раз и используется всеми приложениями, что с ней слинкованы. А когда каждая тащит свою - получаем загрузку n штук почти одного и того же.
Ну и что? Потерять ещё 5-20Мб в памяти сейчас не проблема.
Статичная компоновка частично решает и эту проблему. Какой-нибудь глобально-установленный Qt может много весить, но если каждая программа с ним статично компонуется, то весит он сильно меньше, т. к. неиспользуемый в этой программе функционал отбрасывается компоновщиком.
ряд базовых библиотек (вроде kernel32.dll), которые стабильны, насколько это возможно (вплоть до багов)
Только "чтобы жизнь малиной не казалась" компиляторы MS любят по умолчнию цепляют стандартные вызовы системных функций не к этим базовым библиотекам, а к конечным вида api-ms-win....dll, желательно работающим только под последние версии Windows.
GLIBC нужна динамическая компоновка для таких вещей, как модули NSS
В NixOS (где каждый исполняемый файл может использовать собственную версию в том числе и glibc) эта проблема решается принудительным использованием nscd (точнее, nsncd) — в этом случае динамическая загрузка модулей NSS выполняется только процессом nsncd, а все остальные процессы могут быть слинкованы как угодно (хоть статически) с любой версией glibc, поддерживающей совместимый протокол nscd (а в этом протоколе, насколько я понимаю, очень давно ничего существенного не менялось).
Я понимаю что статья перевод так что вопрос скорее к сообществу.
Я всегда не понимал этих постоянных "сломов" п.о после обновления дистрибутивов.
Возьмем например linux\macos\ios
Да в общем то можно только IOS
меняется одна десятичная часть например 8.0- 8.1 а то и вообще 8.0.1 и софт ломается. Если версия повысится до 9 то вообще никакой совместимости.
Если разработчик обновил по то вам повезло. если нет то все. В описании тут же появляется требование к НОВОЙ версии ОС. А программа условно уровня калькулятор (да просто хоть форма с картинкой). Почему так все завязано на систему? Почему не убирают зависимости от разных версий системных библиотек и API ХОТЯБЫ там где это ну реально не требуется?
Как пользователям то жить? Или давайте так. Как минимизировать пользователю зависимость от обновлений? или как научиться легко исправлять ситуацию?
Можно сколько угодно ругать windows но у них совместимость великолепная по сравнению с nix.
Кстати к вопросам. Вот недавно как раз прочел, что у винды есть механизм складывания одинаковых библиотек в т.н. хранилище. и оттдуа уже по ID от нужного ПО поступает запрос от конрктеного приложения. Это сильно упрощает жизнь.
Есть ли у NIX что-то подобное или предвидится?
Есть ли у NIX что-то подобное или предвидится?
Слишком много мейнтейнеров. Слишком много веток\направлений. И, вероятно, даже не в этом дело. Например, systemd.
Можно сколько угодно ругать windows но у них совместимость великолепная по сравнению с nix.
Ещё бы у них не было совместимости — одна контора (вроде как) клепает. Великолепной не назвал бы. Некоторое ПО для WinXP в Win7 приводило к BSOD. Не единожды.
не хотелось бы вдаваться в частности т.к. общей сути это всеравно не изменит. у меня и ПО под XP падало на XP. =) Зато есть вещи которые прекрасно написанные под хп работают и в десятке по сей день.
Но сказать я не это хотел. Суть в том что механизм хранилищ в винде полноценоо появился как раз с VISTA
Я так вообще для себя грубо разделяю ыинды на 1. win9x..., 2. xp, 3. vista - 11
механизм складывания одинаковых библиотек в т.н. хранилище
Есть ли у NIX что-то подобное или предвидится?
Уж полвека как есть, /usr/lib называется
Только проблема как раз в том, что разные программы на самом деле хотят РАЗНЫЕ библиотеки
Можно сколько угодно ругать windows но у них совместимость великолепная по сравнению с nix.
Потому что в это очень серьёзно вложились. Все (ну ладно, почти все, но далеко не каждому нужно тёмное добро из ntdll.dll) системные вызовы документированы и работают во всех системах, начиная с той, в которой они были введены, если в документации прямо не указано иное.
Системные либы не зависят от языка, на котором написан прикладной софт. Можно писать хоть на чём: C, C++, Delphi и даже на ассемблере - системные вызовы отдельно, библиотеки языков отдельно. В свой процесс подгружай что угодно, хоть свою CRT c БДиШ - это никак не будет влиять на динамическую линковку с WinAPI.
Есть ли у NIX что-то подобное или предвидится?
Кто готов в это вложиться? Ответ очевиден: никто. И до тех пор, пока не появится массового платёжеспособного спроса, вряд ли что-то изменится.
ну...попробую возразить вам приведя в пример MACOS
Денег - ярды. Хомячков....миллионы... но никакой совместимостью, (возьмем за основу последние 20 лет начиная с макос семейства кошачьих) и не пахнет. Никто ничего не улучшал. С этого примера я фактически и начал.
Сами ломают СВОЙЖЕ софт РЕГУЛЯРНО. Про тормоза на новых версих ОС даже вспоминать не буду. выходит за рамки.
и это все при условии что пишут они под КОНКРЕТНОЕ железо. т.е. область совместимости еще более сужена должна быть.
Так может дело не только лишь в деньгах, а в самой сути nix систем? (ну ладно....ладно...все мы знаем что эппл жадны и просто не вкладываются =))
ну...попробую возразить вам приведя в пример MACOS
Это же секта "Think Different". Во многом благодаря этому, бизнес-софт часто обходит macOS стороной: слишком много заморочек ради небольшого процента устройств. Во всяком случае, в России.
Ну снова возражу. Если уж мак ос это небольшой процент....то каков прцоент у линуксОв? ;-)
Маководов в россии все больше. даже я это вижу. многие хотят или уже перешли на маки. Хотя конечно массовость еще далеко. Но ведь не только о россии речь =)
Но вот если помножить еще и на пользователей IOS устройств... то тут уже огромное кол-во устройств.
А про бизнес софт... вы что имеете ввиду? Очень много того что есть под винду коммерческого - есть на макос, чего как раз нету на линуксах.
Или под бизнес-софт вы имеете ввиду что-то под конеркетного заказчика? ту не знаю.
у линуксов меньше доля рынка - но твой супербизнес софт достаточно собрать под RHEL, Ubuntu LTS и может под какой-нить SLES/SLED и Debian для эстетов и всё, у тебя 95% этого рынка закрыты на срок жизни LTS-релиза.
а так он прав - у яблока всё очень сложно с поддержкой, чтоб там нормально работало - надо писать apple way, и не факт, что через год "вот этот вот правильный путь" не объявят Deprecated и не скажут "переписывай давай!" (например выкинут все 3Д апи кроме металла без переходного периода)
Ну и я почти о том же.
Вопрос как раз - как пользователям для себя вопрос совместимости решать? Вот прекартила макос обновляться. А софтинкой польоваться хочется. MAcos не настолько закрыта как IOS и подшаманить можно и без джейлбрейка.
Все настолько сиильно меняют чито никакое добавление "фалов\либ" из прошлых релизова ОС не помогут?
там спектр от "поправил Info.plist и полетели" и до того, что таки реально надо держать старую ос.
Про такие ньюансы Apple - их пользователи в курсе, знали что брали :).
И вообщем то это помогает поднимать например поддержку новых системных фич софтом (ну а кому лень - те не достойны чтобы их софтом пользовались юзеры Apple и платили за него). Другое дело что да
Бывает и не только про совместимость бывает еще тотальный Think Different. Например - смотрим какая версия OpenGL в macOS самой последней, сравниваем с Windows (или Linux). Смотрим почему - так (про Vulkan и что есть MoltenVK я в курсе).
3. MS специально занималось диким хакерством для поддержки старого несовместимого софта, который давно не поддерживают сами разработчики, возможно вышедшие из бизнеса. Патчение на лету ошибок доступа к памяти, специальные затычки воспроизводящие давно исправленные глюки в api если конкретные программы на них полагались итд. У oldnewthing жутковатые истории были. На какую только гадость ни пойдут эти MS ради денег.
Зато клиент доволен и платит денюжку MS. С линуксом платили бы охотнее, если бы по итогу раскатка ПО шла в три клика без всякого головняка с либами, сборками, патчами. Если уж разработчики воют, то что говорить про бизнес.
ну...линуксов платных тоже достаточно. но вот про совместимость в них я не слышал.
любопытно...а если бы коммерческие дистры пошли по пути совместимости.... люди бы охотнее переходили? )
ну чисто технически тот же RHEL как-то так и идет, там к концу поддержки мажорного релиза "под капотом" уже процентов 70-80 переписано из апстрима, но можно запустить всё что угодно, включая дрова для прям изначального релиза. проблема в том, что на уровне одного вендора такое делать - очень дорого, а комунити ты не заставишь фиксить баги, потому что у них там впереди С++666, ржавчина 25.7 и новые виды грызунов привезли, и там можно писать на 3 строчки кода меньше!
Предложенное решение очень похоже на то, что я неоднократно озвучивал на ЛОРе: https://www.linux.org.ru/articles/development/17183665?cid=17185690
Snap/Flatpak только загоняют проблемы дальше и последние версии glibc уже настолько забыли о совместимости, что именно на glibc последних нескольких лет стали ломаться многие старые игры.
Другая проблема - что нельзя несколько libc использовать одновременно - такое вполне работает на windows, который спокойно грузит в процесс несколько версий msvcrt/ucrt и они не дерутся между собой, но в linux это всегда проблема т.к символ не привязан к модулю и даже если несколько libc загрузятся, то символы будут использоваться от одной
сии glibc уже настолько забыли о совместимости, что именно на glibc последних нескольких лет стали ломаться многие старые игры.
а можно именно примеры этого? они же ломающие изменения под версионирование затаскивают.
такое вполне работает на windows
то-то из мира Windows пришло выражение "DLL-HELL"...
то-то из мира Windows пришло выражение "DLL-HELL"
Именно там из-за этого DLL-HELL приложили кучу усилий. Появилась подсистема Side-by-Side, когда загрузчик DLL научился подавать либу с нужной версией из кучи с одинаковым названием. Появился .NET, где тоже всё гораздо лучше с зависимостями. Не сказать, что всё работает абсолютно без проблем, но уже давно не сталкивался с ошибками несовместимых библиотек. В никсах этот путь ещё только предстоит пройти.
К сожалению, ленивые разрабы решили его не проходить, вместо этого пихая каждое приложение в контейнер. В принципе такой подход сейчас везде популярен - магазины приложений во всех ОС делают песочницы, но в линуксе эта песочница сделана с максимальным оверхедом. У меня один вопрос к флетпаку - почему они не решили поднимать kvm виртуалку со своим ядром под каждое приложение для полной изоляциии
В основном конечно ломается софт из эпохи до-sse, когда требование к выравниванию стека было 4 байта. Ещё были проблемы с 32битным файл-оффсетом.
Насколько я помню, это уже нормально не работает:
https://habr.com/ru/articles/91986/
Просто оставлю тут ссылку на Nix: nixos.org, очень многие проблемы сабжа уже решены, если рассматривать софт/заголовочные файлы/библиотеки как чистую функцию от ее зависимостей (runtime и build) и от файла установщика (то есть, от хэша), без состояния.
А Nixpkgs на данный момент действительно самый крупный и одновременно актуальный репозиторий линуксового ПО.
К сожалению никс решает эти проблемы только для себя и внутри себя. Сторонние бинарные пакеты на никсе это двойная боль. Унести с никса бинарные пакеты на сторону - кажется заманчиво, но тоже боль - из-за графических драйверов.
Если бы в мире остался только никс, то мир бы стал лучше. Жаль что это маловероятно.
Ощущение пересоздания Holy Build Box :-)
я на базе него делал дистрибуцию. На момент 2016-17 годов работало на всех машинах с glibc. Запустил сейчас на свежем Manjaro: сам бинарь запустился. Но есть проблемы с окружением font-config. "Пофиксилось" без пересборки.
Собирать со старой версией - тоже не панацея. Линкуясь к символами старых- версий glibc ты получаешь неэффективные/небезопасные bug compatible реализации. Где-то может всплыть ASLR bypass, где-то просто очень тормозной вариант функции.
В бородатых glibc memcpy делал memmove вообще. Есть конечно ещё способ - перед линковкой снести из glibc версии тех символов, для которых нужна актуальная реализация. То есть взять какой-нибудь 2.13 и снести версии с memcpy, математических функций и libc_start_main - тогда по идее будет одновременно и совсестимый со всем бинарь и при этом ему будут доступны все современные функции.
Но такое может легко сломаться.
Ещё на что стоит обратить внимание при сборки portable бинарей - то, как сделан android ndk.
Там вместо настоящих библиотек лежат специальные заглушки, которые линкуют правильные версии символов. Возможно основная проблема даже не в том, что влинковываются последние версии символов, а в том, что в линуксе софт линкуется к системной glibc. В то время в других ОС есть специальные тулчейны с платформами, таргетирующие определённую версию ОС и дающие гарантии совместимости. В windows вообще линковка идёт не к dll, а к специальным либархивам с thunk'ами - если софт собран с windows7 sdk в режиме совместимости с XP - он и будет бинарно совместим с XP, даже если линковался на windows 11
Про сборку со старой версией я имел ввиду динамическкую линкову: в новой версии libc старый символ так или иначе будет содержать исправления безопасности. По крайней мере я шёл по этому пути, эдакий компромисс.
в линуксе софт линкуется к системной glibc
Собственно в несколько непрямом (даже извращённом) виде это и позволяет (позволял, сейчас там более свежий базовый дистрибутив используется) сделать Holly Build Box. Я собирал туда свежий компилятор Gcc, нужные версии Qt, а окружение мне давало просто условно, нужную версию "системной" libc, эдакая "платформа". Да, сильно натянуто, но, в целом, решить можно.
Мы не считаем, что наворачивание дополнительных слоёв — это приемлемое решение.
Ну а «мы» считаем, что приемлемое.
Даже можно не просто дубликацию библиотек и легковесную среду ядра делать (как во flatpak), а целую виртуалку под каждую программу поднимать. Например, так можно делать в Qubes OS. Память дешёвая, процессоры быстрые, накладные расходы можно делать небольшими.
За контейнизацией и песочницами будущее десктопа (как минимум по типу как в Андроид), а не вот этим всем, что у автора.
За контейнизацией и песочницами будущее десктопа (как минимум по типу как в Андроид)
И получится тоже как у Андроида, когда файлы нельзя нормально обрабатывать несколькими программами, потому что каждая из них только свою песочницу видит (и от других старательно охраняет). А все общение - через какие-то сторонние кривые углы. Для безопасности, может, и полезно, но неудобств приносит массу.
Да, каждая программа в своей песочнице. И файлы между песочницами перекидывать. На Андроиде достаточно удобно делать это через меню Share.
Это реальность мобильников и ближайшее будущее десктопов. Если не настоящее, учитывая что куча софта ставится из flatpak/snap уже сегодня.
А как иначе? Не давать же каждой программе всемогущий доступ ко всем файлам пользователя без всякой на то нужды.
На Андроиде достаточно удобно делать это через меню Share.
Ну да, ну да. Вот хочу я сейчас, скажем, записать звук с внешнего проводного микрофона, наложить звук с bluetooth микрофона, добавить спецэффектов/музыки/сообщения из плеера и выдать все это обратно в линию/наушники.
Или принять звук по bluetooth с одного смарта на другой (связано с предыдущим сценарием, т.к. далеко не всегда аттенюатор на микрофонный уровень есть)
Или программу-автоответчик хочу, которая может поднять трубку, проиграть сообщение и потом записать сказанное.
Могу я это сделать? А вот нет. Все зарезано напрочь разной изоляцией и (не)разрешениями. Причем часть из них, как утверждается, часто(но не всегда) даже аппаратные, вроде невозможности читать/писать в линию телефонного разговора. Вот не судьба было выдать/принять цифровой голосовой поток их телефонного модуля (на том же кристалле сейчас уже) туда, где userspace операционной системы мог бы до них дотянуться?
То, что автоответчика в Андроиде нет - это дурное решение Гугла (я сам категорически против, считаю, что это плохое решение, и тоже хочу себе автоответчик-антиспам). Нет никаких технических ограничений из-за контейнеров и песочниц с тем, что такой функции нет. Гугл могли бы добавить API для автоответчиков, и в песочнице он был бы доступен.
Ужасное состояние двоичной совместимости Linux (и что с ним делать)