Разработчики проекта Debian объявили о реализации повторяемых сборок для всех официальных Live-образов Debian 12.10, а также для сборок всех значительных сред рабочего стола из репозиториев Debian 11, 12 и 13 (testing). Подготовлена инструкция, при помощи которой на основе доступных в репозитории исходных текстов пользователи могут сформировать свои Live-образы, на 100% идентичные на бинарном уровне с предоставляемыми проектом готовыми Live-образами...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=62961
Ждём новостей о новых Live дистрибутивах "для админов"? =)
Как будто раньше что-то мешало печь болгеносы в промышленных масштабах.
Особенно после появления специализированных "дистрибутивов для создания дистрибутивов" типа T2 SDE, позволяющих делать новые не приходя в сознание. Хотя, по правде сказать, и до этого скрипты позволяли не особо голову включать...
Вопрос не в блогеносах, а в верификации. Возможность сборки ибнарно идентичного образа говорит о том, что опубликованные исходные тексты соответствуют тем, из которых создан распространяемый бинарный образ. И если вы не собираетесь верифицировать, это не значит, что никто не станет верифицировать.
А вот ты возьми и сделай по отдельному iso образу для всех сред рабочего стола имеющихся во вселенной, хотя бы тех что перечислены в Википедии. Такого нет ни в Ubuntu ни в этом вашем Arch.
Причём здесь это? Вы просто хотите сбить важную новость от Debian. Кто ещё реализовал систему повторяемых сборок?
>Вы просто хотите сбить важную новость от DebianКак это сбить?
>Кто ещё реализовал систему повторяемых сборок?Как всегда NixOS и GuixSD впереди планеты всей, debian здесь в роли догоняющего. Без всяких оговорок типа
>Тест повторяемых сборок в репозитории Debian Testing провален для 819 пакетов (2.2%)У альта что-то есть, не знаю точно, воспроизводимы ли у них ISO или нет. У opensuse https://www.opennet.dev/opennews/art.shtml?num=61023
Неплохо-неплохо.
-1 вектор атаки, хотя закладки в блобах никуда не денутся
Минимизируй использование блобов. Драйвера видеокарт только открытые.
NVIDIA - поставляет блобы, поэтому его в ядре нет.
И как это сделать?Берем видеокарту на чипе от AMD. Код открыт и лежит в kernel, mesa и т.д. вот толку от этого нет без бинарных прошивок см. https://packages.debian.org/bookworm/firmware-amd-graphics.
С картами от зеленых ситуация ещё хуже.
Вопрос только по картам синих, как с ними обстоят дела?
Может эксперт не в курсе, но бинарные микрокоды запускаются блоками железа, а не в ОС пользователя.
Нет разницы, где запускается код. Есть вопрос в том, насколько много блобов нужно для работы железа
> Нет разницы, где запускается код. Есть вопрос в том, насколько много блобов
> нужно для работы железаКакая для тебя разница, вшит микрокод в UEFI как у синих или лежит на диске как у красных.
Если у тебя штеуд вместо видео - нормально!
Если у тебя аМунЪдя - терпимо... в принципе - даже ничего!
Если халк зелёный - сливай ... закрытый дравер и не ЕММ! :)
>Если у тебя штеуд вместо видео - нормально!
>Если у тебя аМунЪдя - терпимо... в принципе - даже ничего!Как минимум микрокод останется, а это уже блоб
Этот блоб ограничен блоком IOMMU.
В чем смысл, если не 100%?
Например: система на вашем компьютере на 99% не содержит вредоносного кода.
Тут булева переменная - или верифицирован на 100%, или сборка от левого Васяна.
в чем смысл вопроса, если на системе не 100% пакетов установлено?
у меня со всем ненужным хламом, который лень удалить, бинарных пакетов меньше 4 тысяч
> В чем смысл, если не 100%?
> Например: система на вашем компьютере на 99% не содержит вредоносного кода.В чём смысл запирать дверь в своём доме, если нет 10 метрового забора с пиками и рва с крокодилами вокруг, я правильно понял ваш посыл?
Ну так можно не использовать пакеты, которые не прошли тест на повторяемость сборки
У альтовцев такие инновации уже мхом покрылись от старости, а эти только очнулись. Бгг.
Получается что в 3,1% будут закладки?
Тогда это ни кому не нужно.
> Получается что в 3,1% будут закладки?Не ставь себе пакеты копмилируемые раст'ом и тому подобным.
И у тебя будет 100%.
Так это, без Раста сейчас ни куды, ни туды и не сюды.Слава Расту!
Евангелистам да. Для остальных - это игра детей в песочнице.
У тебя какие-то проблемы с растом?
А вас настойчивость АНБ в продвижении раста не напрягают?
Типичный кексперд. Вместо выводов на основании неопровержимых фактов, вы строите теории заговора. Вот интересно, если АНБ начнёт рекомендовать есть хлеб, использовать вилки вы в отместку на рис и палочки перейдёте?
А вот тут вы попали очень точно. Вы видимо не в теме, как и большинство хлебоедов, но поизучайте про болезни с ним связанные. Начните с слова глютен.
>Вы видимо не в темеДа
>как и большинство хлебоедовА как называют тех кто не едят хлеб? А то мне нужно новое достижение на стенку повесить
При чём здесь раст? Здесь играет роль только неосилят0рство дебиановцев. Механизм для воспроизводимых сборок давным давно изобретён: nix. Его даже успели форкнуть в виде guix. Но дебиановцы вместо того, чтобы выкинуть deb на свалку истории до сих пор подкладывают костыли
> При чём здесь раст?Его компилятор не умеет в повторяемую сборку. Разработчики другим заняты.
Packer, Vagrant и так позволяют это делать.И у Fedora есть технология (bootc) более привлекательная, которая позволяет использовать OCI образы операционных систем для загрузки, они быстрее собираются и лучше кэшируются, не расходуя сетевой трафиг зря.
> https://wiki.debian.org/ReproducibleInstalls/LiveImages#cons...
> The GNOME image requires about 17GB during building, so you'll need sufficient memory.ого жесть какая
> И у Fedora есть технология (bootc) более привлекательнаяЭто вообще о другом. Не путай теплое и мягкое.
> Это вообще о другом. Не путай теплое и мягкое.о том же, это вы путаете
повторяемость в bootc гарантируется по тегу образа, причем тут другая технология загрузки, на которую вы пытаетесь сослаться (да?), она тут вторична, определитесь вам шашечки или ехать
> причем тут другая технология загрузки,Она тут совсем не важна. Важна повторяемость сборки из исходников ВСЕХ пакетов.
Пока не все. Но сильно близко к этому.
> Важна повторяемость сборки из исходников ВСЕХ пакетов.так собирайте при сборке OCI образа или что-то мешает?
> так собирайте при сборке OCI образа или что-то мешает?То что компиляторы не всех языков умеют в повторяюмую сборку. А те что умеют требуют плясок с бубном.
> То что компиляторы не всех языков умеют в повторяюмую сборку. А те
> что умеют требуют плясок с бубном.Всё, что вы собираете в OCI образе, можно собирать 1 раз, а далее переиспользовать закэшированные слои. То есть вам на функционал комлилятора в данном случае фиолетово.
> То есть вам на функционал комлилятора в данном случае фиолетово.Вот именно здесь вы и путаете теплое с мягким.
В данном случае совсем не фиолетово - это главная фича.
Об этой фиче новость.
Вы же излагаете о второстепенной, легко решаемой проблеме.
> Об этой фиче новость.
> Вы же излагаете о второстепенной, легко решаемой проблеме.Я не понимаю о чем вы, в новости говорится:
> При формировании повторяемых сборок учитываются такие нюансы, как точное соответствие зависимостей; использование неизменного состава и версий сборочного инструментария; идентичный набор опций и настроек по умолчанию; сохранение порядка сборки файлов (применение тех же методов сортировки); отключение добавления компилятором непостоянной служебной информации, такой как случайные значения, ссылки на файловые пути и данные о дате и времени сборки. На воспроизводимость сборок также влияют ошибки и состояния гонки в инструментарии.
вы хотите сказать, что всё это не возможно в сборке OCI образов? Может у вас где то недопонимание, как оно работает там? отвечу сразу - точно также.
Вот именно на сборки пакетов и идет концентрация новости. Всякие образы к делу не относятся.В новости они упоминаются лишь потому что 100% ПАКЕТОВ используемых в образах уже собираются повторяемо.
Главное тут ПАКЕТЫ собираются ПОВТОРЯЕМО.
> Вот именно на сборки пакетов и идет концентрация новости. Всякие образы к
> делу не относятся.
> В новости они упоминаются лишь потому что 100% ПАКЕТОВ используемых в образах
> уже собираются повторяемо.
> Главное тут ПАКЕТЫ собираются ПОВТОРЯЕМО.Нет, новость про образы, которые состоят из пакетов, внимательно читайте.
Вы можете пакеты собирать отдельно от образа, а потом их включить в финальный образ. Или собиарть пакеты тоже в образе и экспортировать артефакты из него, это гораздо удобнее, чем чистым Jenkins раннером собиарть в системе, а потом это систему удалять всё равно. Это избыточный расход ресурсов, чем когда мы на одной машине собираем несколько пакетов, все в рамках своего образа и не захламляют всю систему.
Очевидно вы читаете какую-то другую новость.Ибо тут акцент на том что 100% ПАКЕТОВ собираются повторяемо.
Хотя в не Live образов еще работать и работать.
>переиспользовать закэшированные слоиВы эти слои глазками читали?
>Всё, что вы собираете в OCI образе, можно собирать 1 раз, а далее переиспользовать закэшированные слоиЭто не то. Повторяемость - это сборка на двух разных машинах даёт одинаковый результат
Тут фишка как бы в том, что Вася Пупкин может собрать у себя дома ОС и "убедиться", что она ничем не отличается от уже установленных файлов. Из чего делается вывод, что проверяющий не является частью ботнета.Остаётся не вполне ясным:
1. Если специально обученные люди запрятали в установочные файлы руткит, почему бы оно не подправило результаты воспроизводимой сборки, что бы Вася был спокоен?
2. Если Вася и так собирает, зачем ему нужно уже собранное?
3. Что появилось раньше: яйцо или курица, а так же почему в этой дилемме не рассматривается петух?
> то появилось раньше: яйцо или курицаКонечно курица. Яйцо же бывает не только куриным
Поправка: Раньше было, конечно же, яйцо.P.S. Зачем я это пишу? )
Да. У некоторых экспертов они есть.
> 3. Что появилось раньше: яйцо или курица, а так же почему в этой дилемме не рассматривается петух?Конечно яйцо, это как третье незначимое состояние (яйцо - х) при двух значимых (петух - 1, курица - 0) :)
>> 3. Что появилось раньше: яйцо или курица, а так же почему в этой дилемме не рассматривается петух?
> Конечно яйцо, это как третье незначимое состояние (яйцо - х) при двух
> значимых (петух - 1, курица - 0) :)Очевидно, что яйцо получается в результате сложения этих "1" и "0", но может принимать значение "0" или "1".
яйцо результат переноса сложения петуха и курицы, то есть сначала появляется "пустой - х" разряд (клетка, ячейка, желток, белок, скорлупа одним словом), а потом уже зародышевый диск, который принимает значение 0 или 1. То есть яйцо по факту - ячейка хранения.
Коммутативно ли сложение в таком множестве? Является ли элемент "0" нулевым?
> Коммутативно ли сложение в таком множестве?Так это зависит от определения групповой операции "сложения". "Сложение" как процесс "спаривания" в природе - коммутативно. Но тут надо еще дать определение процесса "спаривания" и оно может быть неоднозначным (палка и два конца). Можно принять "спаривание", как "самец вставляет пипку в пипку самки", можно и "самка насаживает пипку на пипку самца". И оба определения как бы "однонаправленны" и с виду как бы не коммутативны, но ведь результат ведь один в обоих определениях операции. Отсюда если две операции (пусть два определения спаривания не равны) дают одинаковый результат, тогда они эквивалентны.
x - самец
y - самка
z - яйцоПусть
f(x, y) -> функция "спаривания" - "самец вставляет пипку в пипку самки"
g(y, x) -> функция "спаривания" - "самка насаживает пипку на пипку самца"
при x =/= y, тогда
f(x, y) = z
g(y, x) = zполучаем
z = z --> f ~ g --> s - фактически одна и таже операция.
Отсюда
s(x, y) = s(y, z)
И переписав в операторном стиле получаем:
x + y = y + x
> Является ли элемент "0" нулевым?
В смысле нулевым? Может вы имеете ввиду существование нейтрального элемента по "операции" (сложению)? Так это все зависит от определения свойств операций на группе.
> s(x, y) = s(y, z)опечатка: s(x, y) = s(y, x)
Яйцо является "третьим состоянием" временно (пока "уровень сигнала" в цепи "переполнение-перенос" не устоялся). Потом это либо курица, либо петух. Не ясно как отнять от него исходное слагаемое, и что получится. :)
xxx| 00 | 01 | 10 | 11
_______________________
00 | 11 | 10 | 01 | 00
---|-------------------
01 | 10 | 11 | 00 | 01
---|-------------------
10 | 10 | 11 | 00 | 01
---|-------------------
11 | 00 | 10 | 01 | 11
---|-------------------Если взять вот такую таблицу сложения (подобно XOR, только за раз два бита берется), то она частично коммутативна, то есть и коммутативна и анти(не)коммутативна.
Свойства:
Подобно XOR шифрованию.
a + b = c
a + c = ba + a = d
a + b =/= b + aСуществует a + b = a, и единственное a + a = a
"Исключающее ИЛИ", оно же XOR - это сложение в кольце. Грубо говоря, множество из 0 и 1 со своей алгеброй. Абстракция второго порядка, такое мало кто понимает (мне проще сказать, что я не понимаю). Но схемотехнически очень просто реализуется, проще сложения, поскольку перенос (переполнение) не учитывается. Вот такой парадокс.
>2. Если Вася и так собирает, зачем ему нужно уже собранное?Собирать можно не на дебиане. Можно на условной генте собрать дебиан, а уже им либо повторно собрать, либо первого раза хватит.
>>2. Если Вася и так собирает, зачем ему нужно уже собранное?
> Собирать можно не на дебиане. Можно на условной генте собрать дебиан, а
> уже им либо повторно собрать, либо первого раза хватит.Так, Дебиан тогда вообще зачем?
> Packer, Vagrant и так позволяют это делать.Они соберут мне binutils?
> Они соберут мне binutils?Не вижу препятствий, в рамках процесса сборки нет ограничений по командам, что хочешь можно собрать и засунуть в образ
> Не вижу препятствий, в рамках процесса сборки нет ограничений по командам, что хочешь можно собрать и засунуть в образТак собрали и засунули и получили повторяемость бинарной сборки из исходников?
Или никто этого не делал?
> Так собрали и засунули и получили повторяемость бинарной сборки из исходников?да, тут ключивой момент как вы собираете, из какого коммита или зеркала сорцы берете для сборки. По-хорошему, поднимаете свой Nexus и используете его как кэширующее зеркало и для повторяемых сборок с нужных версий библиотек.
> да, тут ключивой момент как вы собираете, из какого коммита или зеркала сорцыЭто прям мрак.
Какое зеркало? Какие комиты?
Исходники берутся из пакетов исходников.
> Это прям мрак.
> Какое зеркало? Какие комиты?
> Исходники берутся из пакетов исходников.Дышите глубже, если нервы. Если пакетов с исходниками уже нет, как будете брать? Если вам нужна полная повторяемость через 15 лет (2040 год), вы собираете версию программы за 2025 год, уже может не быть пакетов с исходниками, единственный источник правды это Git код, из которого вы по тегу формируете сами пакет с исходниками. А лучше напрямую собирать из кода.
не, он прав, это мракв контексте новости "повторяемость" значит, что взяв исходники у дебиана и следуя инструкции от дебиана мы получим бинарный артефакт, который побитово совпадает с таким же артефактом, скачанным у дебиана.
Это способ показать и проверить, что в артефакте нет ничего дополнительного.> Если пакетов с исходниками уже нет, как будете брать?
то и проверять уже поздно, т.к. в пакете могли быть патчи, отсутствие которых не позволит вам получить такой же артефакт (а кроме патчей там еще много чего)
> в контексте новости "повторяемость" значит, что взяв исходники у дебианаА кто вас заставляет ограничиваться контекстом новости? :) нужно шире мыслить
> то и проверять уже поздно
нормальная отмазка, вот только она не прокатит, если возможность собрать есть из кода всё таки будет и вам срочно припрет собрать именно эту версия пакета или снапшот дистрибутива, все что, а у вас есть это код.
> вам срочно припрет собрать именно эту версия пакета или снапшот дистрибутива, все что, а у вас есть это код.В общем случае она не будет именно этой версией пакета или снапшота - это будет ДРУГАЯ версия пакета или снапшота, которую вы можете попробовать использовать на свой страх.
Вот только кроме всам для всех остальных это будет васяносборка, с возможными проблемами и троянами.
> В общем случае она не будет именно этой версией пакета или снапшота - это будет ДРУГАЯ версия пакета или снапшотаПочему, если это собрана из ровно того же кода. Debian ничего не скрывает, видно как именно пакет формируется, видно его код.
В конце концов, задумайтесь, как дистрибутивы-форки Debian делают. Ровно также, как я говорю.
Потому что в пакетах исходников лежат патчи, дополнительные скрипты настройки и т.д и т.п.А форки debian - это не debian. Это ДРУГИЕ дистрибутивы.
Хотя некоторые и берут debian'овские пакеты напрямую. Но только часть.
> Потому что в пакетах исходников лежат патчи, дополнительные скрипты настройки и т.д
> и т.п.И? Что вы хотите этим сказать? Собирайте с этим всем тоже.
> А форки debian - это не debian. Это ДРУГИЕ дистрибутивы.
Спасибо Кэп.
> Хотя некоторые и берут debian'овские пакеты напрямую. Но только часть.
Да, они вольны как угодно собирать свой вариант пакета, а могут 1 в 1 сделать как делает Debian. Вы почему-то делаете из этого проблему. CI код по сборке открыт и также версионируется вместе с пакетами, что вам ещё не хватает, чтобы собрать 1 в 1 пакет, как в репозитории Debian? У вашего пакета только контрольная сумма, подпись и дата будет другими, а функционально это будет тот же пакет с вашей подписью на вашем частном репозитории.
> И? Что вы хотите этим сказать? Собирайте с этим всем тоже.Тогда весь вопрос в том, что если отдельно правила и патчи - отдельно исходники, каждый со своего репозитария. То система неустойчива - из-за возможности убить повторяемость сборки дитрибутива удалением одного репозитария.
> Спасибо Кэп.
Так и нечего на них кивать. Они никак не относятся к теме повторяемых сборок.
> Да, они вольны как угодно собирать свой вариант пакета, а могут 1 в 1 сделать как делает Debian. Вы почему-то делаете из этого проблему. CI код по сборке открыт и также версионируется вместе с пакетами, что вам ещё не хватает, чтобы собрать 1 в 1 пакет, как в репозитории Debian?
Как уже выше говорил. Если вам повезет, то через пару тройку лет - соберете. Не повезет - нет.
> А кто вас заставляет ограничиваться контекстом новости? :) нужно шире мыслитьА зачем разводить оффтоп под новостью? Зачем врываться с "Packer, Vagrant и так позволяют это делать." если это не соответствует действительности и содержит отсылку к новости?
> нормальная отмазка
это не отмазка. В организации повторяемых сборок есть цель, если пакет с исходниками утрачен, то достигнуть этой цели практически нереально
> вот только она не прокатит, если возможность собрать есть из кода всё таки будет и вам срочно припрет собрать именно эту версия пакета или снапшот дистрибутива, все что, а у вас есть это код.
пакет с исходниками это не только код. На повторяемость сборки может влиять порядок обработки файлов, а на сортировку строк влияет локаль и т.д.
Так что если цель собрать определенную версию программы, то проблем нет, если верифицировать бинарь от дебиана, то поезд ушел
> А зачем разводить оффтоп под новостью? Зачем врываться с "Packer, Vagrant и так позволяют это делать." если это не соответствует действительности и содержит отсылку к новости?Где оффтоп? Оффтоп это когда мы тут про политику начём, и то связь можно найти. А это всё укладывается в рамки создания повторяемых образов.
> это не отмазка. В организации повторяемых сборок есть цель, если пакет с исходниками утрачен, то достигнуть этой цели практически нереально
Если код не утрачен, вы формируете пакет точно также как это делает Debian, их CI/CD код по формированию пакетов открыт также, вам никто не запрещает его переиспользовать у себя и содавать свои пакеты и подписывать их своим ключём.
> пакет с исходниками это не только код. На повторяемость сборки может влиять порядок обработки файлов, а на сортировку строк влияет локаль и т.д.
> Так что если цель собрать определенную версию программы, то проблем нет, если верифицировать бинарь от дебиана, то поезд ушелИ это всё наглядно видно в их CI системе (https://wiki.debian.org/SalsaCI), они же ничего от вас не скрывают.
> Где оффтоп?у Packer и Vagrant другие цели и задачи. Они нужны чтобы облегчить распространение софта и настроек за счет возможности воспроизвести окружение по какому-то описанию с последующей упаковкой этого окружения. Если дважды запустить сборку образа, то вы получите два идентичных с т.з. компонентов, но бинарно разных образа, т.к. у вас нет возможности повлиять куда на ФС запишется конкретный файл
В новости же пишется про подход, который позволяет проверить, что образ целиком и полностью собран именно из тех исходников, что указано, т.к. он будет бинарно идентичным. Это не способ создания окружения или сборки пакета, это способ проверки
> Если код не утрачен, вы формируете пакет точно также как это делает Debian, их CI/CD код по формированию пакетов открыт также, вам никто не запрещает его переиспользовать у себя и содавать свои пакеты и подписывать их своим ключём.
я не могу сформировать такой же пакет. Они пропатчили уязвимость, патч лежал рядом с исходниками. Что было внутри патча? А были ли какие еще скрипты пре-/пост-обработки? При сборке использовали -O2 или -O3? А какие еще флаги использовали в rules?
> И это всё наглядно видно в их CI системе, они же ничего от вас не скрывают.
расскажи вот этому товарищу https://www.opennet.dev/openforum/vsluhforumID3/135203.html#85
У большинства пользователей нет прав отследить всю цепочку от исходников до пакета на фтп, как и нет возможности проверить, что пакет на фтп не был изменен позже.
Так что воспроизводимая сборка в данном случае это способ доказать, что не было добавлено закладок. Или наоборот, обнаружить, что их добавили
> Если дважды запустить сборку образа, то вы получите два идентичных с т.з. компонентов, но бинарно разных образа, т.к. у вас нет возможности повлиять куда на ФС запишется конкретный файлна https://wiki.debian.org/ReproducibleInstalls/LiveImages говорится, что нужен свой проксик
apt-cacher-ng running on http://127.0.0.1:3142когда мы собираем у себя, не важно Packer, Vagrant или OCI образ, мы точно также можем использовать механизмы кэширования (не обязательно такой же проксик, полно других способов). Разумеется, чистым инструментом вы не достигните повторяемости. Везде нужен свой подход.
> Они нужны чтобы облегчить распространение софта и настроек за счет возможности воспроизвести окружение по какому-то описанию с последующей упаковкой этого окружения.другими словами для сборки образа. Я часто этими инструментами сам собираю образы разных систем. Разумеется я учитываю нюансы, которые могут влиять на повторяемость, там где нужно переизпользую кэш.
> на https://wiki.debian.org/ReproducibleInstalls/LiveImages говорится, что нужен свой проксикчтобы ускорить пересборки и не дудосить серверы дебиана. А то сейчас как все ломанутся проверять
> мы точно также можем использовать механизмы кэширования
только сначала определиться, сколько кэш хранить. И зачем
> другими словами для сборки образа.
mkisofs тоже образ собирает, т.е. делает то же самое, что и пакер. (на всякий случай — нет, не то же самое)
Другими словами слово reproducible для новости и для пакера имеет немного разное значение
> чтобы ускорить пересборки и не дудосить серверы дебиана. А то сейчас как
> все ломанутся проверятьпрокси именно обеспечивает повторяемость в пределах 6 часов
Меньшая нагрузка на сервера их вряд ли заботит, CDN проплачен на годы, на деньги фонда, там тариф обычно - анлим и эта забота CDN провайдера уже, а не Debian.> только сначала определиться, сколько кэш хранить. И зачем
"within its regular 6 hour update cycle" говорится на Wiki
> Другими словами слово reproducible для новости и для пакера имеет немного разное
> значениевсе зависит от кэширования
Никто ничего брать не будет.Это вообще не относящаяся к теме новости детализация.
Все пакеты исходников debian доступны.
Если они не доступны, то и пересобирать нечего.
А значит и сравнивать нечего.
> Если они не доступны, то и пересобирать нечего.Если нужна будет именно версия, то это не прокатит за причину. У вас не будет выхода, кроме как формировать пакет самому точно также как это делает Debian, только на своём локальном зеркале. Или компилить нужную версию из кода.
> Если нужна будет именно версия, то это не прокатит за причину. У вас не будет выхода, кроме как формировать пакет самому точно также как это делает Debian, только на своём локальном зеркале. Или компилить нужную версию из кода.Вот только вопрос повторяемости сборки сам собой отпадает.
Ибо вы будете собирать другое из другого.
И то что вы соберёте - не будет обладать никаким доверием пользователей debian.
> Вот только вопрос повторяемости сборки сам собой отпадает.
> Ибо вы будете собирать другое из другого.Нет вы будете собирать так же как Debian, в CI коде по сборке каждого пакета это наглядно видно в их репозиториях. Вас никто не заставляет собирать своим способом, просто переиспользуете их CI.
Если вы восстановите все артефакты используемые при сборке пакетов - то да. Повторить можно.Но тогда вызывает сомнения факт утраты пакетов исходных кодов.
Если проект debian прогорит - дольше всего будут доступны пакеты исходников.
Причем тут кэши? Вы их глазками читали?
>а также для сборок всех значительных сред рабочего стола из репозиториев Debian 11, 12 и 13 (testing).Это каких? Огласите весь список пожалуйста.
Debian Wiki в принципе содержит только: GNOME, Plasma, Xfce, LXDE, LXQt, MATE. Я не знаю это не половина, хорошо если треть от всех имеющихся.
Это не Windows, можешь свой DE на коленке сделать и будет работать
Для начала неплохо бы собрать с уже существующими.
Запускаться.
А работать ... а особенно хорошо работать ... ну такое :(
Достичь уверенной повторяемости без чистоты (as in purity) пакетного менеджера невозможно. По определению. Физически. В свою очередь сделать чистый пакетны менеджер на императивном ЯП сопряжено с таким количеством головняка, что никто и никогда этого делать не будет.Поэтому это какая-то беспонтовая фигня. Никто не поручится, что это будет работать и работать корректно.
https://linderud.dev/blog/nixos-is-not-reproducible/NixOS is not reproducible according to the Reproducible Builds definition.
When is a build reproducible?
A build is reproducible if given the same source code, build environment and build instructions, any party can recreate bit-by-bit identical copies of all specified artifacts.Neither Nix or NixOS gives you these guarantees.
> Neither Nix or NixOS gives you these guarantees.Автор статьи не учёл Nix Flake, который уже несколько лет стандарт в Nix и Nix OS. Он как раз и гарантирует повторяемость (не 100%, но по крайней мере на столько, на сколько это возможно), потому что заставляет Nix скачивать пакеты и все зависимости строго по закреплённому sha коммиту. Пользователь сам решает, когда sha коммиты обновлять в lock файле.
А для 100% повторяемости достаточно поднять своё зеркало, которое будет кэшировать все артефакты и библиотеки.
> А для 100% повторяемости достаточно поднять своё зеркало, которое будет кэшировать все артефакты и библиотеки.Недостаточно. Нужно еще устроить пляски с бубном вокруг каждого компилятора.
> Недостаточно. Нужно еще устроить пляски с бубном вокруг каждого компилятора.я больше про установку заранее скомпилированного.
>A build is reproducible if given the same source code, build environment and build instructions, any party can recreate bit-by-bit identical copies of all specified artifacts.
>Neither Nix or NixOS gives you these guarantees.Очень интересно, на чём основано столь смелое утверждение. Поскольку собрать воспроизводимое сборочное окружение на nix проще простого
И, кстати, пакетный менеджер Nix написан на императивном C++.
Но *nix-ники даже этого не знают :))))
> :))))Простите, но похоже вы из дуpки сбежали? Или ещё в дeтcкий сaдик с мамой за ручку ходите?
Пишешь из-под анонима на неформальном форуме, а апломб такой, словно твои комменты начальство читает... и принимает к сведению.
> Поэтому это какая-то беспонтовая фигня. Никто не поручится, что это будет работать и работать корректно.Проверку чексумм уже выкинул отовсюду?
Вопрос может показаться провокационным, но я серьезно. Какой линукс можно поставить на 286 комп с 2 мегабайтами ОЗУ? Недавно стал счастливым обладателем сего ретрожелеза. И в принципе возможно ли это? Может что-то из *BSD?
https://www.freedos.org/
>286 комп с 2 мегабайтами ОЗУ?Просто выкинь это на помойку, или отдай в компьютерный музей в вашей деревне (если есть).
А если нет - то ставь MS DOS и не ### моск :)
> > Просто выкинь это на помойкуВы, неуважаемый (извините, но повода уважать ВАС у меня нет), походу, даже не представляете сколько такое железо стоит сегодня. Рекомендую открыть ибей и посмотреть на цены.
Отдай мне.
Он по сути прав. Линус Торвальдс начинал писать на 386, а тут 286.
286 ничем не отличается от 386 кроме скорости. На обоих есть защищённым режим и поддержка расширенной памяти (286 может кажется до 16 мегабайт).
>Какой линукс можно поставить на 286 комп с 2 мегабайтами ОЗУОчень интересно, что вы собрались на нём делать. Беглый поиск говорит про ELKS и Minix.
Артимович как-то утверждал, что Red Hat содержит закладки спецуры, так как в исходниках у него одно, а в бинарниках слегка другое.
можно подумать, что у всех остальных не так
А ты проверь, а не думай.
Утверждавший о Red Hat проверил или не проверил? "Слегка другое" мало о чём говорит.
У тебя есть уникальная возможность лично задать ему этот вопрос, он персонаж довольно известный.
Например, когда другой довольно известный персонаж -- К.К. -- нарыл в Скайпе "шпионскую функциональность", он подтвердил свою находку кодом, получающим список процессов. Потом выяснилось, что таким образом проверялось наличие отладчика и обнаруживший оказался немного в луже, но одно дело ошибаться, а другое - трындеть, ссылаясь на ОБС.
Ну вот и потребуй у него неопровержимых доказательств. Лично мне это не особо интересно, я и без того понимаю какая шваль работает в Red Hat.
> Ну вот и потребуй у негоНа основании чего я буду требовать? Того, что какой-то ноунейм наплёл про него невесть что?