![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
waqurFlatpak — платформа дистрибуции настольных приложений для Linux.
Фичи:
* установка приложений в обход основного репозитория дистрибутива
* единая платформа для всех дистрибутивов
* приложение распространяется с зависимыми динамическими библиотеками, т.е. не зависит от динамических библиотек основной системы (которые могут быть несовместимы с приложением, или внезапно стать таковыми в результате обновления системы)
* можно устанавливать одновременно несколько версий одного приложения
* платформа использует контейнерные технологии ядра Linux для создания песочниц приложений (bind mounts, namespaces, seccomp)
http://flatpak.org/
Фичи:
* установка приложений в обход основного репозитория дистрибутива
* единая платформа для всех дистрибутивов
* приложение распространяется с зависимыми динамическими библиотеками, т.е. не зависит от динамических библиотек основной системы (которые могут быть несовместимы с приложением, или внезапно стать таковыми в результате обновления системы)
* можно устанавливать одновременно несколько версий одного приложения
* платформа использует контейнерные технологии ядра Linux для создания песочниц приложений (bind mounts, namespaces, seccomp)
http://flatpak.org/
no subject
Date: 2017-06-03 04:27 pm (UTC)Особисто для себе я на лінупсі поставив крапку.
no subject
Date: 2017-06-04 08:35 am (UTC)На самом деле, это такая попытка сделать телодвижение в сторону binary-friendly линукса, т.е. немного дизраптнуть устоявшуюся модель разработки, когда авторы выкладывают свои поделия в виде исходников на github (или другую аналогичную платформу), мейнтейнеры каждого Linux-дистрибутива и *BSD ports collection поддерживают свои патчи, которые с разной степенью успешности удаётся протолкнуть в upstream. Разумеется, эта устоявшаяся модель имеет массу недостатков, среди которых основные — колоссальные усилия по поддержке новых версий софта (мейнтейнерам дистров надо постоянно быть в тонусе: при каждом обновлении в апстриме обновлять свои патчи, иначе софт быстро перестанет даже собираться, не говоря уже о работоспособности); ну а также недружественность этой модели к разного рода коммерческому софту (shareware, видеоиграм, CAD-системам, СУБД и т.д.). Причина банальна — нет исходников.
Это же на самом деле вопрос социально-политический, а не технический. Секта свидетелей Столлмэна орёт "это не баг, это фича!" и категорически не приемлет любой формы отказа от двухуровневой модели "автор — мейнтейнер". Для них отсутствие Photoshop и AutoCAD на Linux'е — благо, нормальный порядок вещей и индикатор того, что всё идёт по плану. С учётом количества подобных кадров в Linux сообществе, исход затеи с flatpak — не определён.
Даже если на время забыть о политических вопросах и посмотреть чисто технически — в какой мере решение проблем установки тут поможет — перспективы туманны. Установка приложений — лишь 10% проблемы. Оставшиеся 90% — это отсутствие стабильных API, таких как GDI и DirectX. Под "стабильностью API" в данном контексте понимается возможность запуска в 2017 году GUI-программ, скомпилированных 20 лет назад, т.е. в 1997 году. Без изменений в исходниках и без перекомпиляции. В один прекрасный день Linux научится таким трюкам, и вот тогда можно будет начать 20-летний период ожидания, по завершении которого и объявить долгожданный "год Linux'а на desktop'е".
(Дополнение.)
Вообще говоря, API — это не только функции из DLL/so, структуры и флаги. Даже добавлением GUIDов и виртуальных таблиц COM-классов вопрос не исчерпывается. API — это также имена и форматы файлов /etc/** /usr/local/etc/** и ~/.** (или, что то же самое, схема ключей/значений реестра и файлов в %APPDATA%). API — это также имена и форматы файлов /proc/** и /sys/** (или схема имён родных NT объектов, которые можно увидеть в программе WinObj). API — это также "обратная сторона Луны" — всё то, что видят разработчики драйверов (функции, структуры, флаги, реестр, sysfs, procfs, sysctl...). Всё это должно быть документировано (MSDN), поддерживаться, или хотя-бы не меняться в течении десятилетий (иначе на платформе просто ничего не успеет вырасти).
Маленький пример: Setup API из Windows 10.1703 (компонент, отвечающий за установку драйверов) поддерживает INF-файлы (информация об установке драйверов), которые могут содержать директиву Ini2Reg (команда на преобразование INI-файлов в ключи/значения реестра, маленький этап в процессе установки драйвера). Всё дело в том, что на Windows 10.1703 можно устанавливать драйверы от любых версий Windows, начиная от NT 4.0, ну а во времена NT 4.0 (1996 год) при установке драйверов и самой Windows, разумеется, этому компоненту Setup API надо было вовсю поддерживать миграцию из INI-файлов в реестр, т.к. INI-файлы использовались вместо реестра в Windows 3.11 (в 1993 году).
Вот когда Linux достигнет такого уровня стандартизации и совместимости по части GUI API, драйверного ядерного API, API установщика и ещё дюжины подобных API (а не только голого POSIX), тогда и появится основание воспринимать эту систему всерьёз.
no subject
Date: 2017-06-04 07:41 pm (UTC)По поводу Фотошопов и автокадов. Пока в линупсе нет стабильных долговременных API, как в Windows, никакого фотошопа не будет. Но это техническая, служебная сторона. А идеологическая значительно хуже. У лапчатых есть специфическое сектантское видение окружающего мира: дескать, никто не должен разработчикам и линуксу, поэтому жрите наш кактус в том виде, в каком он есть в каждый отдельный момент времени. Тот же несчастный GIMP много лет не могут сделать полезной программой, поскольку его делают программеры для программеров, в итоге он со всех сторон оборудован скриптовыми и прочими инструментами, но непригоден для использования в обработке изображений для полиграфии или Fine Arts. Аналогично обстоит дело почти со всем прикладным ПО для линукса: пионеры по сто раз переписывают с нуля плейеры, иконки, новые красивые обои, DE, тулкиты — но всё это в конечном итоге неюзабельно и бесполезно для обычных людей-потребителей прикладного ПО. Это закономерное следствие из крайне порочной и пагубной парадигмы так называемой промышленной разработки, в которой принято аксиомой, что время разработчика стоит дороже, чем железо. Пока эта ошибочная установка не будет отброшена, FOSS никогда не приблизится к людям. В MS это отлично понимают, хоть они и очень жадная и недобросовестная в конкуренции контора, поэтому принципиально возможно (хоть и небезопасно) пользоваться продуктами MS, которые были выпущены более десяти и даже двадцати лет назад, даже с ограниченным сохранением обратной совместимости для множества прикладного ПО. А ведь это именно то, что нужно покупателю.
В обсуждени systemd в моём журнале можно было во всём великолепии видеть эту идею: «нам хорошо и мы никому ничего не должны». ОК, не должны — но тогда кому и зачем вы вообще нужны? А за кулисами деликатно покашливает менеджмент RH, который как бы ни при чём.
К дополнению ещё пару слов добавлю. Стабильные базовые вещи, долговживущие API и стандарты, по крайней мере некоторые, есть. Например, формат ELF, POSIX, те же традиционные Иксы. Проблема, потенциально, с такими системами в том, что они сложны и требуют мозгов для понимания, а code monkeys хотят чего-то простого, чтобы быстро зарабатывать деньги. Им, как показала жизнь, на переносимость плевать. Они считают, что поскольку их время стоит дороже, то юзер докупит пару планок памяти и новый процессор к выпуску следующего мажорного релиза какой-то поделки. А это в реальной жизни не так, не будет этого. Людям невозможно объяснить, почему пустая (ничего не отображающая) страница в Chrome занимает в памяти несколько десятков метров памяти, когда десять лет назад этого количества памяти было достаточно для результативной и эффективной работы в каком-нибудь PageMaker, которая позволяла неплохо кормить свою семью.Я прекрасно помню время, когда в моём рабочем компьютере было 32 МБ памяти и процессор PI-133, это была дорогая и быстрая на то время машина — и я мог делать всю свою работу и получать за это зарплату. За прошедшие два десятилетия никак не изменились рабочие задачи, но почему-то потребителя постоянно вынуждают покупать каждые три года новый компьютер и к нему системное и прикладное ПО. С какой радости? Я не буду этого делать. И в корпоративном секторе такой подход — норма. Инструмент подбирается и приобретается для использования, в идеале, навсегда, без неоходимости его замены. И риторика code monkeys о дороговизне времени разработчика вызывает в этом контексте только отторжение. Если, допустим, фирма купила лицензии на Windows XP и Office 2000 для своих рабочих мест, достаточные для работы, то единственное, чего она хочет от поставщика — гарантийного и послегарантийного сопровождения (в виде исправления найденных ошибок и заплаток безопасности), желательно пожизненного. Характерно, что MS не препятствует этому, не отзывает лицензии. То есть люди бизнеса отлично понимают, что нужно бизнесу.
no subject
Date: 2017-06-05 07:47 am (UTC)Ну ладно, Canonical наняла Леннарта Поттеринга и запилила какую-то очередную ненужную свистоперделку. Ну ладно, демон всего, так анти-юниксово. Ну ладно, запихнули всё в PID 1, так анти-инженерно (помню всеобщее веселье, когда какая-то левая библиотека начала бросаться assert'ами в PID 1, и соответственно ронять всю систему в kernel panic). Наверное, и форкать долгоживущий процесс с большой фрагментированной кучей — это анти-инженерно. Ну ладно, бинарные логи, которые ни погрепать, ни восстановить по кусочкам с разваленной файловой системы (помню шутки на эту тему: "дотянулся проклятый Баллмер", по аналогии с "дотянулся проклятый Сталин"). OK, такие вещи происходят постоянно, ну подумаешь, какие-то дураки реализовали какую-то очередную глупость; им заплатили; в других дистрибутивах никто ничего не заметил, или сделал вид, что не заметил; и через пару лет все благополучно забыли; в целом по индустрии от этого никому не холодно и не жарко.
В этот раз вышло по-другому. Почему?
Сам я предпочитаю FreeBSD взамен Linux, и наблюдаю за systemd-драмой как бы со стороны. К счастью, в *BSD системах никто не собирается менять init, он так же хорош, как и 40 лет назад в AT&T Version 6 UNIX. Кстати, он не сильно изменился с тех пор. Это как хорошее вино — со временем становится только лучше и лучше.
no subject
Date: 2017-06-05 08:34 am (UTC)Началось это всё чуть раньше. Несколько лет назад появились сомнительные (на мой взгляд) инновации: ConsoleKit, Polkit (ранее — PolicyKit) и пр. Все они имеют отношение к freedesktop.org и по странному совпадению написаны ребятами из RH. То есть Леннарт не один этим занимается, а systemd это уже ягодка на готовом торте. RH эти вещи продвигает как универсальное наше-всьо, особенно для основных DE, а тамошние
идиотыпионеры сделали это зависимостью. Чтобы использовать актуальные популярные DE с неустранимой зависимостью, дистрибутивы теперь вынуждены тащить и systemd. Это в самом кратком и общем виде. Кое-что для чтения по теме: Desktop environments and systemd dependencies.В случае с Дебианом имел место натуральный беспредел, но тоже хорошо понятный и объяснимый, если смотреть с точки зрения замыкания на вендора как главной цели мероприятия. Сама дискуссия прошла мимо моего внимания (поскольку я достаточно долго отсутствовал в гражданской жизни по уважительной причине). По отзывам, которые читал в форумах, получается следующее: для получения желаемого результата RH оказал влияние на процесс
выборов руководства(не выспался) голосования совета Дебиана по поводу systemd, после чего противников systemd там не осталось. Ссылок по друкой у меня нет, но это легко гуглится. Это большая победа для RH, поскольку теперь из крупных поставщиков линукса никого вне охвата systemd, по сути, не остаётся.То, что нам пытаются представить в виде некоего прогрессивного технического решения, на самом деле является целенаправленным планомерным привязыванием экосистемы линукса к RH. Но у большинства лапчатых не хватает мозгов понять и осознать происходящее. А гуру, вроде Торвальдса, будут молчать в тряпочку, потому что зарплату им платит или иными способами помогает, как можно догадаться, тоже та самая заинтересованная фирма.
Пикантная деталь истории в том, что всё это проворачивает отнюдь не Microsoft, Oracle или IBM, а самая, казалось бы, вовлечённая в FOSS компания, флагман движения за открытость и свободу.
no subject
Date: 2017-06-05 08:54 am (UTC)no subject
Date: 2017-06-05 09:16 am (UTC)Defining the Problem
To be written.
(ConsoleKit 0.4.1 Documentation)
Ребяткам настолько пофигу, что они не потрудились прописать базовые цели своей деятельности.
И вот это всё миру предлагают как востребованные технические инновации.
no subject
Date: 2017-06-06 05:20 pm (UTC)no subject
Date: 2017-06-04 07:55 pm (UTC)no subject
Date: 2017-06-04 08:03 pm (UTC)В зрелом уже сложившемся дистрибутиве важна не только возможность управления бинарниками, но и пересборки их, включая и ядро, под конкретную машину, и даже пересборки всего «мира». Как это реализовать с унифицированными пакетами, если нет единого органа, который контролирует все внутренние стандарты? Идея-то хороша, но за много лет не смогли на практике прийти даже к единому и приемлемому для всех стандарту на иерархию файловой системы или состав базовой системы. И это сложно критиковать, поскольку дистрибутив как таковой — это продукт идеи о специализации ПО. Совместить более-менее узкую специализацию з реальной универсальностью, по-моему, ещё никому не удавалось. :)