Всё правильно говорит.

ну так очевидно же.

Он умолчал о нескольких крупных проблемах репозиторной модели: неоперативность мантейнеров, deps-hell, невозможность охватить всё множество софта, и т.д.

Домохозяйки и школьники будут в шоке от напиханных масс в их ось и перейдут на десяточку. Так проблема решится сама собой. А каноникал перестанет пороть ерунду и займется очередным убунтофоном, хотя наверное это тоже ерунда...

А открытый софт весь качественный и безбажный... мммдя.

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

Это лучше дырявой и статически слинкованной версии openssl, о которой никто не знает.

неоперативность мантейнеров

в арче такой проблемы нет, там всегда самые свежие баги!

Ну, неоперативность мейнтейнеров с приходом snap никуда не исчезнет, даже хуже, нужно ещё что бы тот кто собирает snap пересобрал snap.

Репопроблемы

Он умолчал о нескольких крупных проблемах репозиторной модели:

• неоперативность мантейнеров — решается сторонними репозитариями. Решение не идеальное, но компромисс достаточно неплохой.
• deps-hell — в Guix'е ад зависимостей невозможен
• невозможность охватить всё множество софта — всё множество софта не нужно никому и никогда, всякому пользователю нужен лишь нужный ему набор программ, не более. На самом деле этот пункт это некорректное разворачивание пункта 1.

Все правильно сделалсказал

Но без решения наподобие снапа или какого-то стандартизированного метода упаковки бинариков - типа «засунул бинарик и либы в спец архив, везде работает» - в линуксе не будет CADов, проф. софта для работы со звуком/видео, включая аппаратные всякие там микшеры, и прочая прочая.

Ну и будет Canonical на пару со снапами продвигать вирус антикасперского и делов.

One snap to rule them all

Ну, неоперативность мейнтейнеров с приходом snap никуда не исчезнет, даже хуже, нужно ещё что бы тот кто собирает snap пересобрал snap.

Предполагается, что snap будет единственным пакетом такого сорта, поэтому всякий разработчик будет сам упаковывать свою программу в snap.

Но без решения наподобие снапа или какого-то стандартизированного метода упаковки бинариков

запихнуть бинарники со всеми зависимостями, включая libc, и сейчас ничего не мешает

без решения наподобие снапа или какого-то стандартизированного метода упаковки бинариков - типа «засунул бинарик и либы в спец архив, везде работает» - в линуксе не будет CADов, проф. софта

Чуваки unreal tournament в 1998 году как-то скомпиляли, что он до сих пор у меня на свежем арче работает без всяких костылей. Распаковал и запустил.

Кайл, иди вон!
Вот это первая эмоция на мысли Кайла.

Речь про какое-то стандартное решение, типа API. Для того, чтобы бинарик вашей companyname работал без проблем во всех дистрибутивах линукс необходимо: п.1, п.2, п.2,1,.. п.n. И софторазрабы потянутся.

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

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

даже если вдруг мантейнеры обнаружили баг - они его все равно не поправят. Во-первых, есть проприетарный софт, исходников от которого они не нароют никогда. Во-вторых, даже если исходники есть - чтобы их починить нужно быть отличным программистом и быть в курсе всех нюансов и деталей проекта. Но ты не можешь быть одновременно И хорошим программистом С++, И хорошим админом, на это просто не хватит жизни. Такими возможностями (достаточно хорошим скиллом программирования и осведомленностью о состоянии проекта) обычно обладают только непосредственные разработчики проекта, в лучшем случае - еще и девопсы непосредственных разработчиков.

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

возникает вопрос, к чему относятся зависимости - к инфраструктуре, или к функциональности приложения. Это фундаментальный вопрос, разграничивающий области ответственности мантейнеров и разработчиков софта. Мне кажется, что зависимости - это дело в первую очередь разработчиков софта. Потому что в зависимости от выбранных зависимостей, приложение может работать по-разному, например, не работать вообще. И установить это смогут только тестировщики компании-производителя, которые сюрприз-сюрприз - обычно не являются мантейнерами дистрибутива.

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

и никаких проблем с этим нет, такой порядок вещей испокон веков уже

Кайл совершает типичную ошибку админа, пытающегося начать выполнять функции программиста

А в каком месте там функции программиста?

unreal tournament в 1998 году как-то скомпиляли

Он только вышел в 99-м Ж)

КО.

Ну да, а как в раче - 3.5 пакета в main, а остальное пакуют мимикрокодилы - это, конечно, качественно и безопасно.

Мне кажется, что зависимости - это дело в первую очередь разработчиков софта.

Зависимости - да. Их версии - нет.

Речь про какое-то стандартное решение, типа API.

системные вызовы ядра

зависимости - это дело в первую очередь разработчиков софта

Разработчиков и мэйнтейнеров в равной степени, вот его-то и стоит стандартизировать, по возможности не впадая в крайности мэйнтейнеры не нужны!!11 (Ubuntu) и разрабочики не нужны!!11 (Gentoo).

Кто такой main? И я не мимикрокодил, стараюсь как могу.

Ну или как там у них основной репозиторий называется.
А помойка типа AUR явно не качественнее и не безопаснее snap-пакетов.

в бинарном виде там почти 12 тыс пакетов, а если ставить из аура неглядя, то да.

неоперативность мантейнеров — решается сторонними репозитариями. Решение не идеальное, но компромисс достаточно неплохой.

Сторонние репозитории - такой же рассадник троянов как какие-нибудь торренты. Неоперативность мантейнеров решается жёстким maintainer timeout в 2 недели как во FreeBSD, а лучше ещё меньше.

макака, которая пилит мегаприложение с гуем на js будет конечно их учить, даааа

всё множество софта не нужно никому и никогда, всякому пользователю нужен лишь нужный ему набор программ, не более

Всё множество софта нужно всему множеству пользователей.

в Guix'е ад зависимостей невозможен

Я что-то пропустил и Guix стал широко использоваться?

Сорта

Я что-то пропустил и Guix стал широко использоваться?

snap стал широко использоваться? Да что уж там, deb стал широко использоваться? Часто бухгалтеры уже одинэс из deb'ов ставят?

Так Guix это тот самый анекдотический 1% от 1%.

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

«Помойка» же типа AUR или портов FreeBSD... я скажу про последние потому что лучше её знаю, предполагаю что AUR отличается не сильно. Во-первых, сборочные сценарии просты и составляют десятки строк, и убедиться что они не делают ничего злонамеренного может даже гуманитарий. Во-вторых, все изменения в них постоянно контролируются - это видно по maillist'ам где сразу указывают на ошибки в коммитах. Далее, пакет с апстримовскими исходниками верифицируется чексуммой, т.е. гарантируется что мантейнер ли, все ли кто собирает сам из исходников, сборочные ли машины проекта - все видят одни и те же исходники. Далее, при наличии reproducible builds (в порта FreeBSD пока в зачаточном состоянии, в AUR не знаю) можно гарантировать что даже бинарные пакеты не были подменены.

Итого, в нормальной экосистеме с source-based пакетной системой + reproducible builds нет ни одной возможности внедрения злонамеренного кода на пути от апстрима до пользователя, а вопрос доверия к апстриму (который актуален всегда), частично решается тем, что все используют один и тот же пакет, значит будь в нём проблема, вероятность её выявления увеличивается пропорционально аудитории. Опять таки, аудит апстрима автоматически распространяется на всех пользоватетей.

А snap и аналоги это один большой путь распространения зловредного кода. Даже если это пакет СПО, то собиратель пакета мог случайно (как было с qip, например) или намерено добавить туда троян, и об этом никто не узнает. Потом пакет могут подменить на пути до, условно, ftp откуда он раздаётся. Потом в нём. Потом на пути до пользователя, причём до вас лично, и даже если тысяча глаз будут следить за ftp, вам это никак не поможет.

Это всё касалось СПО, а о проприетарщине которая на таких пакетах будет просто-таки цвести, даже говорить не хочется.

Это всё касалось СПО, а о проприетарщине которая на таких пакетах будет просто-таки цвести, даже говорить не хочется.

Конечно не хочется, ведь сказать нечего. snap пакеты решают проблемы с её распространением.

А snap и аналоги это один большой путь распространения зловредного кода. Даже если это пакет СПО, то собиратель пакета мог случайно (как было с qip, например) или намерено добавить туда троян, и об этом никто не узнает. Потом пакет могут подменить на пути до, условно, ftp откуда он раздаётся.

А архив с исходниками на том же ftp подменить не могут, да.

а ей и не нужно

Конечно не хочется, ведь сказать нечего. snap пакеты решают проблемы с её распространением.

Да, но вот я лично не уверен что проблемы с распространением троянов нужно решать, а не создавать.

А архив с исходниками на том же ftp подменить не могут, да.

Не могут, потому что порт проверяет чексумму. В pkgbuild есть SKIP и это позор, на самом деле.

Вот буквально вчера было. У меня в проекте есть зависимость на XML-парсер Saxon. Начиная с какого-то обновления он перестал в XSLT воспринимать HTML version=1.0. Это сделало неработоспособным кусок кода, в том числе те части, от которых нет исходника. Причем это обновление притащил не я, а оно само притащилось в результате разрешения длиннющей цепи зависимостей. Эта проблема решается написанием интерцепторов, которые ловят вызов xsl и препроцессят его ДО попадания в Saxon другим парсером, и в тэге html меняют аттрибут version с 1 на 4.

Более того, в java есть такое интересное поведение, что в зависимости от того, какие зависимости сейчас просто _существуют_, код будет работать еще более по-разному, например - отдавать объекты в совершенно другом формате. В частности, если того же Saxon нет в зависимостях, то автоматически выбирается другой XML-парсер, который отдает другой формат внутренних структур, и код мгновенно рассыпается в труху. Но иногда происходит хуже - не вылетает никаких ошибок, а код начинает просто работать по-другому, идти по другим веткам if'ов итп, выдавая другой результат (который на глаз еще фиг отличишь).

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

У меня на решение всех этих проблем ушел день в отладчике, туча коммитов на интеграцию компонентов, включая декомпиляцию кусков кода которые есть только в бинарном виде (кстати совершенно непонятно, работает ли новый код так же хорошо как его бинарный аналог). Мантейнер бы эту задачу решал ну.. наверное, бросил бы на первой неделе =)

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

В pkgbuild есть SKIP и это позор

SKIP используется для каталогов-исходников из svn/git/etc. Позор мейнтейнеру если он поставил SKIP для тарбола.

Кроме того в pkgbuild есть validpgpkeys.

Да, но вот я лично не уверен что проблемы с распространением троянов нужно решать, а не создавать.

Назло маме уши отморожу, ясно.

Не могут, потому что порт проверяет чексумму. В pkgbuild есть SKIP и это позор, на самом деле.

Для snap-пакетов хэш запрещено проверять?

SKIP используется для каталогов-исходников из svn/git/etc

Это (особенно svn), во-первых, небезопасно, во-вторых, делает невозможным зеркалирование дистфайлов, и в портах FreeBSD явно запрещено. С GitHub, например, качаются только тарболлы, для них как обычно фиксируется чексумма. Да, сделать порт который автоматически ставит версию из master не получится, но я не могу придумать более небезопасной и нестабильной штуки, чем что-то без предварительно проверки (человеком) ставящееся из master.

Позор мейнтейнеру если он поставил SKIP для тарбола.

Ну я навскидку увидел его в пакете хрома. Для eula, правда. Хотя один раз и палка.. в eula_text.html прилетает что-то нехорошее.

Для snap-пакетов хэш запрещено проверять?

И как ты его собрался проверять? И будешь ли? И все ли будут?

Таки зачем я?

Установка пакетов осуществляется из каталога Snap store, доступного через web-интерфейс или инструментарий командной строки. Работа со Snap store напоминает применение традиционных пакетных менеджеров. >Основное отличие в том, что в системе можно одновременно использовать разные версии одной программы. Для распространения приложений предлагается несколько каналов - стабильные выпуски, кандидаты в релизы, бета-версии и экспериментальные сборки.

Я считаю, что переводить всё на snap это бред. В мире открытого софта они не нужны, не хватало на каждую программку тащить все либы. А то будет как с оффтопиком, написал тут для товарища программку с парой кнопок и окошком на GTK, линуксовы бинарь весит 21К, а вендузовый 55-70М в зависимости от архитектуры. И если так будет с каждой программой, то это будет тот ещё ад. Про остальные аспекты Кайл лучше меня сказал.

Единственное но — проприетарщина. С ней надо что-то думать. LSB живёт только в rhel. Альтернатив пока не видно. В таком случае какой-то единый формат для пакетов был бы неплохим выходом, только чтоб с песочницами и прочими безопасностями, с другой стороны чтобы не был прибит гвоздями за интимные места к какому-нить каноникалу или красношляпе.

Делов-то - линковать все зависимости статически.
Только каждый калькулятор будет тащить свою сборку qt, но это ведь не проблема
На андроиде как раз так

Flatpak проверяет gpg ключом

Мысли о snap и прочем кросс-дистрибутивном распространении пакетов в обход ментайнеров дистрибутивов.

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

А в AUR не так? Майнтейнеры арча могут дать честное пионерское, а в убунту не могут? :D

Потом пакет могут подменить на пути до, условно, ftp откуда он раздаётся. Потом в нём. Потом на пути до пользователя, причём до вас лично, и даже если тысяча глаз будут следить за ftp, вам это никак не поможет.

Пакеты snap подписываются ключом Canonical и ты не можешь ни создать, ни поставить snap-пакет без учётки canonical.com.

Т.е. когда раньше блоб поставляли (та же vmware), его не волновали проблемы с безопасностью?

Это та же проблема. Либо баги либо старье, а snap дает возможность выбора, где ставить стабильное старье, а где свежие баги.