Ubuntu Linux исполнилось 20 лет!

xDDDDDDD

Ну да, с какого раза ты поймёшь что кроме корпоративного энтерпрайза есть ещё частные ПК и там не нужно в онлайне анализировать состояние системы и даже высчитывать милисекунды финального этапа загрузки?

Тем временем, оно наисало мне 2*8Мб журнала всего лишь загрузившись в десктоп. А за полчаса работы там стало 2*8,35Мб.

Поставь лимит на 32 мегабайта и пиши в память.

Какую задачу это решит кроме более быстрой перезаписи ненужного мусора на диске?

Делай правильно

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

Он и работает.

Нет. Если выключенный сервис самопроизвольно включается - ну явно что то пошло не так. Если его нельзя отклчать - нужно сказать об этом при попытке выключения.

Просто некоторые сервисы нужны.

Некоторые, но точно не этот. Проверено.

А чо, пусть тебе ядро без всего этого статикой собирают.

Хорошая кстати идея. Так быстрее и проще. Инитрд нужен если у тебя шифрование корня, но мне это не нужно.

Как только они дропнут поддержку старого железа

А зачем им снижать аудиторию, если для этого буквально просто не надо ничего делать?

это перестанет быть проблемой

С чего бы это? Им совершенно некуда девать ресурсы на встраиваемой системе? Вот скажи, зачем роутеру обязательная поддержка cgroups в ядре? А тот же журналд? Могу поспорить что задействование нетворкд только добавит им геморроя, у них и так более гибкая и налаженная система конфигурирования сети.

Лично у меня роутер с 16Мб оперативки и «надо бы там системд запустить» это самая идиотская причина для обновления железа какую можно придумать. Кстати, для понимания: обновление роутера на абсолютно любой другой не решит никакой практической задачи и не улучшит ни одной характеристики ни на 1%. Может быть лет через 5... Но это не точно.

Мы говорили о том, что journald дает возможность ИЗ КОДА легко прочитать лог, это буквально обращение к базе данных.

Да, но ахрена козе баян? Одному юзеру из 100 раз в год может понадобится заглянуть в логи роутера. Для этого не надо писать кода и даже включать мозг избыточно: все пользовательские роутеры управляются со страницы веб-интерфейса, там же встроена вкладка с логами. Десять кликов не уходя из окна браузера и ты читаешь логи. Твой код в лучшем случае сделает задачу дольше и сложнее.

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

open-wrt/dd-wrt тоже это сделали причём ещё тогда, когда системд ещё не появился - у них уже всё было написано, распаршено и прекрасно работало на таком железе, где современный системд просто не сможет запуститься. Самое главное здесь то, что журналд ничем не может улучшить их работу. Всё, совершенство достигнуто ещё до того как он родился, расходимся и не гадим - есть более важные другие задачи.

Поставь себе нормальную ось, типа арча, в котором systemd/journald интегрированы правильно, и посмотри, как это работает у нормальных людей.

Чобы что? Потратить пару месяцев до того, как система начнёт работать? Уже работает. Чтобы после этого прийти к тому, что журналд мне не нужен? Так он и сейчас не нужен. Всё что у меня не работает или глючит - прошивко-драйверо-аппаратные проблемы и он тут в принципе помочь не может.

Шок! — информация об управлении сервисами находится в справочных страницах утилит управления сервисами! — вы бы никогда не догадались, понимаю.

Я всегда был уверен, что у фанбоев какая-то своя квадратно-гнездовая логика и сейчас только убедился в этом. Информация о поведении хелперов при установке пакетов находится в управлении сервисами. Белиссимо.

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

Ты уже приготовил $500?

Во-первых, это бред сивой кобылы.

Во-первых, клоун, эта проблема должна решаться снапшотами. Точка. Либо у тебя надежная файловая система с гарантиями, либо гарантий нет вообще никаких, и все эти пляски не имеют смысла, потому что прерывание dpkg оставит систему в неконсистентном состоянии. Я не понимаю, почему я должен объяснять настолько очевидные вещи.

Во-вторых, вы так удобно проигнорировали все остальные пункты, говорящие об убогости pacman в сравнении с «взрослыми» менеджерами пакетов.

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

Метрика «достаточно хорошо», вообще-то, является ключевой при проектировании архитектуры. Можно упарываться до позеленения и получить переусложненную систему, а можно решить проблему на достаточном уровне, а высвобожденные ресурсы отправить на доработку и сопровождение других частей дистрибутива.

For shell scripts this means that you almost always need to use set -e

almost

Я понял тебя. Знаешь, что побудило написать меня ту заметку? После того, как я напоролся на эту проблему в арче и пошел разбираться в дебиан, я напоролся на эту проблему и там. Так что грош цена твоей браваде про школьные поделки.

Видите, как в новой версии утверждения скромно появилось «…апстримным 6.x», да? ng-tools5 очень даже является апстримным… хоть больше и не развивается там.

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

В общем, ничего нового, всё как всегда…

Не знаю, у меня с первых версий убунты работало чуть больше, чем всё.

А Мандрива = Мандрейк + Коннектива - стыдно этого не знать.

Тем не менее, они этого не отрицают. Просто, может, не договаривают. Ничего страшного тут нет. МакОС тоже нигде не говорит, что она бдсм на самом деле.

Это хорошо. Не все добрались до этого момента.

Ну, я тоже пробую всякое. Астра суть есть тот же дебиан. Ещё тут в треде партиусх посоветовали, гляну. )

Текущие античиты работают только по одной причине - у пользователя нет доступа к железу. Как только этот пользователь получает контроль - тут же вся «безопасность» и рушится.

M$ вполне могут запретить ядерные античиты, вот только они в таком случае предложат API для проверки tampered статуса - по сути DeRbMo на уровне железа/OS. В macOS такое уже реализовано, но редко используется.
SIP отключил - всё, trusted статус потерян, считаем устройство взломанным.

В линуксе такое по дефолту невозможно - пользователь сам управляет системой, поэтому в праве на своём десктопе делать что вздумается вкл. установку драйвера на уровень ядра вместе с античитом. На Windows такой финт не проходит - для этого нужно подписать драйвер, если у корпораций с EAC/BattlEye для этого денег полно, то у читеров ну… вряд ли даже за деньги выйдет. Не зря ж вся эта кривая малварь требует SecureBoot/TPM.
Остаётся только уязвимости в железе искать (взламывать собственное устройство, дивный новый мир), либо использовать unfixable дырки - DMA через Thunderbolt/PCIE и прочее. Но это уже экзотика.

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

TL;DR античиты на линуксе невозможны из-за слишком большой открытости оного.
Дек тоже открыт, единственное, что валв могут сделать - распространять подписанное ядро с включёнными модулями античитов - при этом доступ в систему будет ограничен. Запустился с обычным ядром - доступ есть, онлайндрочилен нет.

P.S. нативные античиты на линуксе менее эффективны по сравнению с виндовыми аналогами про причинам выше, просто пока читеры не особо пользуются этой дырой - так что выгоднее таки разрешить пользователям Deck играть.

Ладно, согласен, размаскировал, перезагрузился, журнал появился, есть информация. И десяти лет, ять, не прошло…

А потом окажется, что остальные твои проблемы решаются точно так же.

Нахрена мне избыточно сложный комбайн для простых действий?

Чтобы не изобретать велосипеды.

А для больших систем нужны другие средства.

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

А ты точно уверен, что он не является обёрткой над системдешным компонентом, оставленным просто для удобства привычных админов?

Абсолютно, я читал исходник. Это буквально свой «старый-добрый костыль».

Ну да, с какого раза ты поймёшь что кроме корпоративного энтерпрайза есть ещё частные ПК

Пользвателю частного ПК вообще плевать на то, пишется ли у него журнал. А если ты пошел журналы отключать, потому что в твоем мировосприятии они НИНУЖНЫ, то у тебя определенно на среднестатистический ПК, а уникальная снежинка. Назвался груздем - полезай в кузов.

Какую задачу это решит кроме более быстрой перезаписи ненужного мусора на диске?

Сохранение лога на случай, если у тебя что-нибудь сломается. Логи, в общем-то, для этого и нужны.

Правильно - это отключить ненужную функцию, жрущую ресурсы.

Нет. Правильно - это сохранять логи в память, если много логов не нужно. Потому что логи всегда нужны в ретроспективе. Когда они понадобятся, окажется, что они отключены.

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

А зачем им снижать аудиторию, если для этого буквально просто не надо ничего делать?

Совместимость тащит за собой технический долг по сопровождению и отжирает ресурсы разработчиков. Когда добавляются новые фичи, надо убедиться, что они работают под старыми ОС. NetBSD, например поддерживает все мыслимые архитектуры, и это их киллерфича. OpenBSD на спарки уже не встает, не говоря уже о FreeBSD.

Им совершенно некуда девать ресурсы на встраиваемой системе?

Оперативная память нужна, чтобы размещать в ней софт. Скажем, на роутере. Если ее очень много - допустим, больше половины - то можно упростить себе жизнь, используя более фичастый компонент, который будет кушать чуть больше памяти, но при этом давать большее удобство для разработчика в плане взаимодействия с этим компонентом. Нет никакого смысла экономить ее ради сферической экономии, потому что на ней все равно ничего другого, кроме роутерного софта, запускаться не будет.

Лично у меня роутер с 16Мб оперативки и «надо бы там системд запустить» это самая идиотская причина для обновления железа какую можно придумать.

Ну да, это твой частный случай. А у меня стоит Dream Machine Pro, на нем 4 гига оперативы и почти полноценный линукс, разрабы поставили побольше памяти, чтобы сделать очень фичастый и удобный софт, снизив при этом застраты на разработку: железо покупается один раз, а софт поддерживается всю жизнь.

На PiKVM у меня вообще полноценный линукс, даже с systemd journald, прекрасно работает на 256 мегабайтах оперативы - это удобно и для меня, и для пользователя, при этом система вместе с моим софтом кушает где-то 100 мегабайт.

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

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

Я тебе объясняю, как с точки зрения разработчика устроена вкладка с логами. Чтобы ты мог посмотреть веб-страницу, сервис для этого должен кто-то написать. А проще всего это сделать, если у тебя сервисами управляет systemd, а логи собирает journald. В противном случае аггрегатор логов придется велосипедить самому, чем все разработчики встраиваемых ОС и занимались до того, как появился journald.

Чобы что? Потратить пару месяцев до того, как система начнёт работать?

Чтобы посмотреть, как работает нормальная ОС. Арч ставится и настраивается за час по мануалу на оффсайте. Сказки про месяц выдумывают те, кто никогда арча в глаза не видел.

Поздравляю убунтоидов и убунтоводов с юбилеем вашего любимого дистрибутива!

Так-то Debian, на котром Ubuntu базируется получается самым важным.

Более того с переходом на Snap, многие, м я например, не могу рассматривать Убунту в качестве основной ОС, а вот Debian, вполне.

Я ни коим разом не преуменьшаю заслуги Debian (сама им пользуюсь!). Просто считаю, что вопрос кто кому больше помог нельзя считать закрытым. Если бы не появление Убунту, вполне могло статься так, что Дебиан был бы чем-то вроде PCLinuxOS или Slackware. Старым, уважаемым и со своими традициями дистрибутивом, который, в общем-то, мало кому нужен.

Когда я спрашивала у брата, почему он на наш домашний компьютер установил именно Debian, тот ответил что-то вроде «Как Ubuntu, но без убунтовских заморочек». Т.е. первичной в этом выборе для него была именно Ubuntu. И он в этом точно не одинок. Я даже здесь на ЛОРе несколько раз встречала комментарии в духе «Зачем нужна Ubuntu, если теперь и Debian просто работает из коробки?». Для многих пользователей именно Убунту стала неким образцом того, какой должна быть настольная домашняя система. И только когда Canonical от этого образца отклонились, эти люди открыли для себя Debian.

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

В целом да. Если античит будет работать только в SteamOS, я согласен.

Кажется, проще не играть в онлайндрочильни

Абсолютно согласен. Мне лично они надоели, только нервную систему себе расшатывать.

ты прямо описала моё знакомство с миром линуксов. когда встал вопрос выбора первого дистрибутива - взял убунту просто потому что когда-то где-то что-то слышал о ней. ну а дебиан как следующая ступень - естественный путь развития.

Информация о поведении хелперов при установке пакетов находится в управлении сервисами. Белиссимо.

При чём тут вообще хелперы, любитель передёрнуть ты наш? Хелперы лишь используют систему управления сервисами, но сам этот механизм политик является частью системы управления сервисами, и поэтому ВНЕЗАПНО описан в документации к системе управления сервисами. А «информация о поведении хелперов», тоже совершенно ВНЕЗАПНО, находится в документации к хелперам.

Ты уже приготовил $500?

Что, решил продолжать клоунаду, всеми правдами и неправдами уходя от ответа?

Во-первых, клоун, эта проблема должна решаться снапшотами. Точка. Либо у тебя надежная файловая система с гарантиями, либо гарантий нет вообще никаких, и все эти пляски не имеют смысла, потому что прерывание dpkg оставит систему в неконсистентном состоянии. Я не понимаю, почему я должен объяснять настолько очевидные вещи.

Просто поразительная некомпетентность! Да будет тебе известно, мамкин программист, что абсолютно надёжных решений не существует, поэтому хороший инженер при реализации подобных систем старается достичь максимума возможной надёжности.

При этом у pacman:

1. Нет ограничений на использование только в файловых системах/блочных устройствах с поддержкой моментальных снимков.
2. Нет информации о такой поддержке и наличии соответствующей конфигурации.
3. Доступен механизм значительного повышения надёжности в применимых системах, не требующий существенных ресурсов на реализацию.

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

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

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

«Достаточно» – это субъективная мера. Случаев, когда частичное или даже полное обновление вызывали поломки в Arch, которых просто не было бы при должной реализации зависимостей на уровне версий символов, – просто дофига. Да даже элементарно зафиксировать версию пакета, в новой версии которого есть серьёзная ошибка, сохраняя при этом возможность обновления других пакетов для исправления уязвимостей или иных ошибок – в Arch это русская рулетка, именно в связи со столь примитивной реализацией зависимостей.

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

Название пакета с такой проблемой – в студию!

Только истинный фанат дебиана будет считать апстримом репозиторий, в котором разработка остановилась еще 11 (!) лет назад, в то время, как существует живое продолжение разработки на гитхабе. Вот на гитхабе - апстрим. А то, что привел ты называется мертвый репозиторий с архивным кодом.

Такого бреда я уже давно не читал. Ты точно разработчик? Что такое «форк» точно знаешь?

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

Даже сообщение импорта первой версии rng-tools5 содержит:

rng-tools5 (5-1) unstable; urgency=low
 .
   * Initial upload of current rng-tools from upstream.

Слово «upstream» сам найдёшь, или помощь нужна?

Я всегда был уверен, что у фанбоев какая-то своя квадратно-гнездовая логика

Тут ты прав, но есть нюанс…

О эти прекрасные блевотные цвета!

При чём тут вообще хелперы, любитель передёрнуть ты наш?

Любитель передергивать тут только один - это ты ;) А хелперы тут при том, что контроль поведения сервисов при установке пакетов относится, очевидно, к установке пакетов.

Что, решил продолжать клоунаду, всеми правдами и неправдами уходя от ответа?

Ну ты же клоунадишь весь тред, почему и мне немножко нельзя? Не должен же я с исключительно серьезной миной парировать все те бредни, что ты тут несешь про взрослые пакетные менеджеры (r) (c) (tm).

Шутка была в том, что fsync гарантирует доставку до железа и подтверждение от него, но не гарантирует, что железо тебе не врет. А взрослый dpkg на это надеется :)

Просто поразительная некомпетентность! Да будет тебе известно, мамкин программист, что абсолютно надёжных решений не существует, поэтому хороший инженер при реализации подобных систем старается достичь максимума возможной надёжности.

Просто поразительная самоуверенность! Да будет тебе известно, клоун, зачем-то притворяющийся инженером, что хороший инженер анализирует задачу и следует ТЗ, а не пытается параноидально достичь абстрактной надежности. Разработка подобной системы всегда требует соблюдения баланса между скоростью, надежностью и разумностью всех требований.

При этом у pacman… доступен механизм значительного повышения надёжности в применимых системах, не требующий существенных ресурсов на реализацию.

Разумеется, это полная чушь. Итак, следим за руками:

1. Dpkg делает fsync и rename на каждый файл, что превращает обновление в синхронный процесс. Очень медленный синхронный процесс.

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

3. Пакман работает очень быстро, потому что не ждет fsync. Это снижает время обновления кратно, благодаря тому, что процесс не является синхронным.

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

5. Таким образом, из-за синхронной записи на диск, dpkg лишь увеличивает вероятность возникновения сбоя. Высокая степень гранулярности пакетов лишь ухудшает эту ситуацию.

Такие вот дела.

И то, что pacman при данных условиях этим механизмом не пользуется, – это или дилетантизм его разработчиков…

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

А еще dpkg - это решение в себе. Если я захочу сделать A/B-систему на снапшотах, то пакман подойдет мне лучше dpkg, потому что не будет создавать оверхед на лишние операции обеспечения целостности, ибо целостностью будет заниматься файловая система. Я просто сделаю снапшот, запущу пакман, и если его работа завершилась успешно, то я буду уверен, что никаких проблем нет. А если нет - откачу ФС и начну сначала. Или не начну, по необходимости.

Кстати, возможно, это одна из причин, почему Valve выбросили дебиан на мороз - слишком тормозной и оверхеднутый пакетный менеджер без значительных преимуществ.

«Достаточно» – это субъективная мера.

Достаточно - это объективная мера соответствия техзаданию, дружок. «Достаточно» становится, когда система отвечает количественным и качественным требованиям.

Случаев, когда частичное или даже полное обновление вызывали поломки в Arch, которых просто не было бы при должной реализации зависимостей на уровне версий символов, – просто дофига.

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

Название пакета с такой проблемой – в студию!

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

Ты применил фразу «полумертвый форк» к апстримному репозиторию, в котором остановилась разработка.

Во-первых, ты врёшь, клоун. Ты взял в кавычки свою собственную фразу, которой не было в моем сообщении. Я писал так: то, что привел ты называется мертвый репозиторий с архивным кодом. Или для тебя слова «репозиторий», «архив» и «форк» являются синонимами? Дружище, ты точно разработчик?

Во-вторых, давай поищем значение слова «апстрим», применительно к опенсорсу. Думаю, Red Hat сойдет за авторитетный источник:

Within information technology, the term upstream (and related term «downstream») refers to the flow of data. An upstream in open source is the source repository and project where contributions happen and releases are made.

Обрати внимание на слово happen. Не happened, лол. Репозиторий, в котором разработка умерла 11 лет назад - это максимум архив старого апстрима, но никак не апстрим, и тем более - не актуальный апстрим. Апстрим - это место, где код разрабатывается. Их может быть несколько, если у нас несколько форков, но в данном случае живой форк только один, и апстрим его лежит на гитхабе.

Слово «upstream» сам найдёшь, или помощь нужна?

Ты всерьез мне подсовываешь ченжлог деб-пакета как доказательство своей правоты? Ты сам-то его вообще читал? Итак, смотрим на дату:

Sat, 03 Dec 2016 12:20:57 -0500

Это было 8 лет назад. Тогда с момента остановки разработки rng-tools прошло всего три года. В 2017, спустя год после этого коммита в ченжлоге дебиана, разработка продолжилась в гитхабе, о чем можно узнать из [https://api.github.com/repos/nhorman/rng-tools](даты создания репозитория rng-tools), см. поле created_at. Получается, что уже на тот момент у нас был архивный реп, и живой, развивающийся код.

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

Тут всё прекрасно. На этом этапе тебя можно просто класть в палату мер и весов. Впрочем, весы и меры опциональны.

Dpkg делает fsync и rename на каждый файл, что превращает обновление в синхронный процесс. Очень медленный синхронный процесс.

eatmydata

При этом прерывание обновления все равно приводит к потере целостности

dpkg-reconfigure -a

Таким образом, из-за синхронной записи на диск, dpkg лишь увеличивает вероятность возникновения сбоя.

Debian - единственное, что не ломалось никогда за 20 лет при сбое в обновлениях.

eatmydata

Мы с одним юзернеймом провели сегодня ради интереса тест. Взяли пустые образа докера арча и дебиана, и попробовали поставить на них kde. В случае дебиана это был kde-full с примерно 2000 пакетов по зависимостям на 5 гигов. У арча мы ставили kde*meta , получилось чуть больше 1000 пакетом размером 6 гигов.

В обоих случаях пакеты были скачаны заранее и мы засекали работу только процесса установки. Тесты были как с eatmydata, так и без. Так вот, даже с eatmydata, апту понадобилось в 5+ больше времени на установку, чем пакману. И я бы понял двухкратный проигрыш из-за числа пакетов, но не в 5 раз, особенно с учётом что на арче ставилось на целый гиг больше.

При этом самой долгой фазой у пакмана была верефикация пакетов и проверка подписей - недеструктивные операции. Деструктивные - разворачивание пакетов и пост-инсталл - заняли примерно 1/3 всего времени работы. Особенно поразило разворачивание тысячи пакетов за 10-15 секунд.

Dpkg же за пару секунд построил зависимости, а потом несколько минут мучительно всё ставил, растянув деструктивную фазу просто до неприличия. И это, напоминаю, с eatmydata. Без него все вообще очень печально.

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

Мы, пожалуй, запишем видосик с этим позором дебиана и выложим в толксы. Вот смеху-то будет :)

Там есть нюанс - это тригеры. Куча полезных вещей, типа menu, когда он тебе создаст меню с приложениями хоть для icewm, хоть для awesome, с полным списком. Но есть и нюанс - эти триггеры тупые - он может по 4 раза за установку вызывать пересоздание initrd для всех ядер, а не один раз после установки. Даже в OpenBSD осилили триггеры, которые вызвваются один раз после установки, а Debian их до сих пор дёргает непонять как - это не dpkg тупой, а apt. Но в любом случае, Debian делает намного больше работы, включая мержи конфигов, триггеры и многое другое, чем пакман, который просто распаковывает пакеты.

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

это не dpkg тупой, а apt

Так установкой занимается dpkg.

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

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

Рад бы видео глянуть!

А потом окажется, что остальные твои проблемы решаются точно так же.

Подождать 5-7 лет? Да, возможно. Когда нибудь и Поттеринг умрёт, вот тогда его точно почият наконец то.

Чтобы не изобретать велосипеды.

Велосипеды очень эффективны для личного использования. А когда у тебя ещё и единый ГОСТ на велосипеды имеется - вообще не вижу проблем.

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

Да, только это настолько легко, что никто не может сделать. А тем кому реально надо и по другому никак - тратят на это чёртову тучу времени или с вероятностью 70-80% возвращаются на сис-В. Иначе бы в том же дебиане были виртуальные пакеты системд-серер, системд-ПК, системд-киоск и системд-контейнер/виртуалка. Но этого не то что в дебиане нет, этого вообще нигде нет! Даже у самих разработчиков системд.

Пользвателю частного ПК вообще плевать на то, пишется ли у него журнал.

В целом да. Как и на то, что винда продолжает дефрагментировать ssd диски по расписанию. Даже после скандала на эту тему там просто тупо переименовали операцию не не стали реализовывать ту самую заявленную «умную ФС, которая сама разберётся требуется ли дефрагментация».

Но лично я решил применить таки совершенно очевидную и имеющую у меня значение оптимизацию. Возможно тут будет как с tmpfs в /tmp - через 10 лет это станет модным мейнстримом.

Сохранение лога на случай, если у тебя что-нибудь сломается. Логи, в общем-то, для этого и нужны.

Ну включу и прочитаю. У меня не энтерпрайз 24/7/365 + штрафы за простой больше 100мс. На ПК вообще логичней игнорировать единичные не повторяющиеся сбои. А повторяющиеся разгрести после включания логгирования, дебаггинга, мониторинга, телеметрии, трассировки и ещё чёрт знает чего, см. инструкцию.

Потому что логи всегда нужны в ретроспективе.

Мне dmesg 1-2 раз в месяц нужен. И то потому что железо - говно и диск иногда физически отваливается. А желания собрать логи журналдом там или сислогом в последние 3 года точно не возникало.

А типовому юзеру вообще не положено знать как пользоваться journalctl. А вот утекающее место на диске и ресурс microSD/TCL/QCL - это важнее.

Ты прям как еще более упоротый вариант Саахрикту: «не всем нужны логи, некоторые хотят гадать на кофейной гуще»

4.2. Я изначально раз за разом утверждаю, что они не нужны по умолчанию. Потому что тот кому нужны логи легко и непринуждённо их включит, а кто про логи не знает - ему и не надо.

Но я вполне согласен если логгиование будет включено по умолчанию, просто ЯТЬ СДЕЛАЙТЕ ЕГО ШТАТНО ОТКЛЮЧАЕМЫМ и не компостируйте мне мозг что оно всем и всегда нужно, поэтому тайком ломать функцию отключения это нормально.

тащит за собой технический долг по сопровождению и отжирает ресурсы разработчиков.

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

Но на примере винды и андроида - они по 10-20-30 лет тянут легаси, экономят на этом хренову тучу времени, просто не создают себе и юзерам новых проблем и всё прекрасно работает.

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

..но вместо этого давайте займём эту память бессмыысленными компонентами системд и ещё логгирование в оперативку вынесем (потому что за флеш для этой задачи придётся отвесить денег).

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

Вот его и надо запускать! самба+nfs+mtp+sshd+ftp вместо чего то одного из этого. Прямо по умолчанию. И ещё торрент-клиент, смотрелка ютуба, музыкальный и видеоплеер и разумеется интерфейс пользователя пофичастей. И без системд всё это может уместиться в 32М вместо 64М.

На PiKVM у меня вообще полноценный линукс, даже с systemd journald

Ну и какую задачу выполняет коза с баяном на однозадачном устройстве, на котором по определению ничего не происходит и ничего не случается?

В противном случае аггрегатор логов придется велосипедить самому, чем все разработчики встраиваемых ОС и занимались до того

Собственно я уже писал что велосипед был изобретён ещё до того, как появился системд 0.1. Можно конечно заново изобрести велосипед, но можно также и взять готовый велосипед и просто вставить его вот в эту область вот этой вкладки. Текстовое поле на html1 и на html5 выглядят одинаково, но первое всё ещё пишется проще. Уж это я знаю.

Чтобы посмотреть, как работает нормальная ОС

Т.е. ровно так, как оно у меня сейчас работает.

Кстати, а у арча есть официальные LTS-релизы хотя бы на 5 лет? Если нет - ну вообще разговор ни о чём. Он не может быть нормальной ОС по определению. Потому что там версия гнома и кде через год изменится.

Обязательно выложим, следи за срачами :)

Подождать 5-7 лет? Да, возможно. Когда нибудь и Поттеринг умрёт, вот тогда его точно почият наконец то.

Практика показала, что тебе достаточно было прочитать ман, что ты ленился делать 5-7 лет.

Велосипеды очень эффективны для личного использования.

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

Но лично я решил применить таки совершенно очевидную и имеющую у меня значение оптимизацию.

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

А желания собрать логи журналдом там или сислогом в последние 3 года точно не возникало.

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

А типовому юзеру вообще не положено знать как пользоваться journalctl. А вот утекающее место на диске и ресурс microSD/TCL/QCL - это важнее.

Типовому юзеру и про сислог знать не надо. А если ты полез в кишки ОС - ты не типовой юзер.

Я изначально раз за разом утверждаю, что они не нужны по умолчанию. Потому что тот кому нужны логи легко и непринуждённо их включит, а кто про логи не знает - ему и не надо.

И это бред. Когда логи внезапно нужны - их не будет. А когда не нужны - нет разницы, куда они пишутся, если это не насилует карту памяти.

Но на примере винды и андроида - они по 10-20-30 лет тянут легаси

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

..но вместо этого давайте займём эту память бессмыысленными компонентами системд и ещё логгирование в оперативку вынесем (потому что за флеш для этой задачи придётся отвесить денег).

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

И без системд всё это может уместиться в 32М вместо 64М.

Разница в стоимости памяти составит пару десятков центов, а разница в сложности поддержки будет колоссальной.

Ну и какую задачу выполняет коза с баяном на однозадачном устройстве, на котором по определению ничего не происходит и ничего не случается?

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

Текстовое поле на html1 и на html5 выглядят одинаково, но первое всё ещё пишется проще. Уж это я знаю.

Как ты будешь выводить туда свои данные? Как будешь выбирать их по дате и сервису? Агрегировать как? Будешь сам пердолиться с пачкой логфайлов, или просто срать в один и пользоваться грепом? М-м-м, удобно ппц.

Он не может быть нормальной ОС по определению

Этот бред я даже комментировать не буду.

А хелперы тут при том, что контроль поведения сервисов при установке пакетов относится, очевидно, к установке пакетов.

Вот только то, что касается хелперов, и так документировано в документации к хелперам, а механизм, которые используют хелперы, документирован там, где он реализован: в системе управления сервисами.

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

И раз уж пошла такая пьянка: а почему pacman вообще положил болт на systemd presets? Почему даже если я установлю enable * в конфигурации systemd-preset, установленный сервис всё равно придётся включать руками?

Когда наконец systemd полноценно интегрируют в Arch? Уж сколько лет прошло, а всё ещё нет поддержки стандартного механизма управления политикой сервисов!

Шутка была в том, что fsync гарантирует доставку до железа и подтверждение от него, но не гарантирует, что железо тебе не врет. А взрослый dpkg на это надеется :)

Ах да, теперь это лёгким движением превратилось в шутку! :D Хорошая попытка, но нет.

Ну а если же ты решил заговорить про возможные глюки железа, то ВНЕЗАПНО, никакие снимки в этом случае также ничего не решают. Тут даже запись-чтение-сравнение не поможет.

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

А в чём сложность сравнить?

• В случае dpkg получим разные версии файлов.
• В случае pacman получим разные версии файлов плюс битые файлы.

Очевидно, мера риска во втором случае выше, чем в первом, просто исходя из аддитивности меры.

Пакман работает очень быстро, потому что не ждет fsync. Это снижает время обновления кратно, благодаря тому, что процесс не является синхронным.

/facepalm

В случае pacman обновление не завершено, даже когда сам процесс pacman уже завершился, поскольку значительная часть данных находится в буферах записи. Нужно как минимум вызвать после этого sync.

И то, что pacman при данных условиях этим механизмом не пользуется, – это или дилетантизм его разработчиков…

Я выше говорил, что ты поразительно самоуверен

Какое чудесное избирательное цитирование! Удивительным образом из моей фразы пропало окончание «в чём я сомневаюсь». Ещё один человек-совпадение…

Если я захочу сделать A/B-систему на снапшотах, то пакман подойдет мне лучше dpkg, потому что не будет создавать оверхед на лишние операции обеспечения целостности

А теперь открываем man dpkg – и что же мы там видим?

unsafe-io: Do not perform safe I/O operations when unpacking (since dpkg 1.15.8.6). Currently this implies not performing file system syncs before file renames, which is known to cause substantial performance degradation on some file systems

И предупреждение в конце:

Warning: Using this option might improve performance at the cost of losing data, use with care.

У pacman же тупо всегда unsafe-io.

К тому же, есть пакет с говорящим названием eatmydata, сделанный в основном для разворачивания в disposable контейнерах, которые в случае чего просто создаются заново, и для которых поэтому не нужно обеспечение целостности.

Кстати, возможно, это одна из причин, почему Valve выбросили дебиан на мороз - слишком тормозной и оверхеднутый пакетный менеджер без значительных преимуществ.

Не надоело фантазировать? SteamDeck вообще образами обновляется, не задействуя менеджер пакетов.

А в дебиане ситуация еще хуже: из-за сильной гранулярности пакетов пришлось изобретать лукап по символам

Ну и чушь…

Мелкость разбиения пакетов тут вообще ортогональна. Какому-нибудь celluloid глубоко фиолетово, поставится ли mpv вместе с libmpv или нет, ему важно наличие нужных ему символов в библиотеке, от которой он зависит. И этот факт не зависит от того, отдельный ли libmpv пакет или нет – да хоть объедини его с кучей других в огромный bundle, суть зависимости от этого не меняется.

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

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

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

Ты применил фразу «полумертвый форк» к апстримному репозиторию, в котором остановилась разработка.

Во-первых, ты врёшь, клоун. Ты взял в кавычки свою собственную фразу, которой не было в моем сообщении.

Да неужели? А давайте прочитаем твоё исходное сообщение на данную тему (ссылка):

В дебиане целых два пакета rng-tools, и ни один из них не является апстримным: один - какой-то странный полумертвый форк, а другой - форк от мейнтейнера пакета бородатой версии с миллионами патчей.

Второй – это пакет rng-tools-debian, так что первый – это rng-tools5. Фразу «полумертвый форк» сам найдёшь, или помощь нужна, клоун?

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

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

Их Флай очень даже годен. Юзал на старом ноуте 1.6, очень даже шустро работал и жрал память как икс-пи в лучшие годы. Но для простых смертных астры нет.

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

Что документация дебиана - говно. Спасибо, я и так в курсе.

И раз уж пошла такая пьянка: а почему pacman вообще положил болт на systemd presets? Почему даже если я установлю enable * в конфигурации systemd-preset, установленный сервис всё равно придётся включать руками?

Ответ на твой вопрос есть в соответствующем issue: https://gitlab.archlinux.org/archlinux/packaging/packages/systemd/-/issues/24

Ах да, теперь это лёгким движением превратилось в шутку!

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

Хорошая попытка, но нет.

Твое мнение тут никого не интересует.

Очевидно, мера риска во втором случае выше, чем в первом, просто исходя из аддитивности меры.

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

Не надоело фантазировать? SteamDeck вообще образами обновляется, не задействуя менеджер пакетов.

Да что ты говоришь! А в CI, видимо, пакеты устанавливаются с божьей помощью. Пересборка любых тестовых образов на арче будет занимать в разы меньше времени, чем на дебиане.

Всё, не пытайся юлить. Valve выкинули твое ненаглядное тормозное барахло на мороз.

В случае pacman обновление не завершено, даже когда сам процесс pacman уже завершился, поскольку значительная часть данных находится в буферах записи. Нужно как минимум вызвать после этого sync.

Так сделай, в чем проблема? Unix-way, мазафака, ду ю ноу ит? Только не забудь, что запись всё еще проводилась по мере работы, поэтому большая часть данных уже окажется на диске к окончанию работы пакмана.

Мелкость разбиения пакетов тут вообще ортогональна.

Нет. Чем больше гранулярность - тем больше ручной работы. Эту ручную работу попытались решить с помощью лукапа по символам, и все равно до конца не решили.

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

Что ты несешь, полоумный? Я вот буквально месяц назад делал чистую установку арча от минимальной системы до работающего KDE. Удивительно, но всё ограничилось установкой метапакетов, которые по зависимостям притянули всё остальное. Так что малой или нет - но все и так прекрасно работает.

К тому же, есть пакет с говорящим названием eatmydata, сделанный в основном для разворачивания в disposable контейнерах, которые в случае чего просто создаются заново, и для которых поэтому не нужно обеспечение целостности.

Удивительным образом тесты показали, что даже с eatmydata дебиановское поделие ухитряется вчистую слить пакману. Что делать будем с этим фактом?

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

А я и не выдумываю. То, что ты отрицаешь реальность - исключительно твои проблемы. Я действительно всего лишь не хочу напрягаться ради неблагодарного юродивого с лора.

Да неужели? А давайте прочитаем твоё исходное сообщение на данную тему (ссылка).

Совершенно не принципиально, что в более раннем обзорном каменте написано про форк - на тот момент мне было плевать, почему вместо свежего софта оба rng-tools в дебиане - окаменелое говно. Технически я даже не ошибся, потому что древний архив с патчами - это буквально форк. Более того, ты отвечал на другое сообщение, и цитировал тоже его. Давай-ка потыкаем тебя носиком в твою же цитату:

… то, что привел ты называется мертвый репозиторий с архивным кодом.

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

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

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

Дурачок на тебя смотрит не в меру красными глазами из зеркала. Ты сам прицепился к первому обзорному комментарию, и проигнорировал остальные мои доводы. Видимо, первый комментарий у тебя считается стабильным, а всё остальное - от лукавого. Логика типичного дебианофанбоя.

Вопрос вообще надо поставить так: почему в дебиане запакован какой-то копролит, который даже пересобирали последний раз в 2022 году, в то время, как в арче есть нормальный, современный rng-tools? Отвечай, клоун.

В случае дебиана это был kde-full с примерно 2000 пакетов по зависимостям на 5 гигов.

Что за ПЦ вы там устроили? С тем же успехом вы могли начать установку КДЕ с гнома, потом перейти на xfce, и мате.

Даже в голову не пришла мысль, что 2000 пакетов и 5 гигов это что то не то? Ну там загуглить, как ставится КДЕ в дебиане?

В последние 15 лет это делается метапакетом задачи/конечный пользователь/KDE Plasma/task-kde-desktop. Лично у меня половина уже установлена, он запросил 450 пакетов, скачать 541М, распаковать на 1800М.

Мы, пожалуй, запишем видосик с этим позором дебиана и выложим в толксы. Вот смеху-то будет :)

Жгите! Я прям даже поржать хочу!

Ну там загуглить, как ставится КДЕ в дебиане?

Так мы и загуглили. Вот буквально взяли и воспользовались официальной документацией дебиана:

There are different options to install the KDE Plasma Desktop in Debian:

• KDE Full | kde-full | The standard/upstream release. Full release of workspace, applications and framework

Неудобно получилось, да, фанбой?

Даже в голову не пришла мысль, что 2000 пакетов и 5 гигов это что то не то? Ну там загуглить, как ставится КДЕ в дебиане?

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

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

А у него что, есть деструктивная стадия? Ну да, есть. Это установка связанных с ядром, загрузчиком, пакетником и инитом пакетов. Любой другой переустанавливается без последствий.

А у него что, есть деструктивная стадия?

Я как-будто с эникейщиком общаюсь. Повторяю определение: деструктивная стадия - это этап записи файлов на файловой системе, и запуск пост-инсталл скриптов, на которые не распространяется волшебная машинерия fsync/rename.

Эксперимент показал, что даже с отключенным fsync dpkg тормозит, как последняя мразь, растягивая деструктивную стадию в несколько раз по сравнению с пакманом. Со включенным fsync всё вообще печально, потому что процесс становится синхронным. При этом ни один, ни другой вариант не решает проблему неконсистентности, напротив, ухудшение надежности идет в прямой зависимости от времени исполнения.

Так мы и загуглили. Вот буквально взяли и воспользовались официальной документацией дебиана:

Там специально для вас жирным шрифтом выделено:

KDE Plasma Task

task-kde-desktop

Debian's selection of applications for a KDE desktop
This is what is installed on a freshly installed KDE system.
It includes a few non-KDE applications: firefox, gimp, orca

Т.е. буквально: дебиан рекомендует этот набор. Как вы вообще читали док на 8 строчек?!

Повторяю определение: деструктивная стадия - это этап записи файлов на файловой системе, и запуск пост-инсталл скриптов, на которые не распространяется волшебная машинерия fsync/rename.

И что такое страшное произойдёт, если я прерву этот процесс вырубанием питания?

Эксперимент показал, что даже с отключенным fsync dpkg тормозит, как последняя мразь

Он тормозит не сильнее, чем распаковка .tar.gz архива на ext4. Было бы странным ждать большей скорости обработки данных.

Там специально для вас жирным шрифтом выделено:

Еще раз повторяю, что мы сравниваем:

• Гранулярность разбиения примерно одного набора софта;
• Длительность деструктивной фазы работы пакетного менеджера с fsync и без.

Т.е. буквально: дебиан рекомендует этот набор.

Какая нахрен разница, что там рекомендует дебиан, если задача была ПОСТАВИТЬ ВСЁ KDE, чтобы иметь максимально одинаковые условия для сравнения?

0 upgraded, 1749 newly installed, 0 to remove and 0 not upgraded. After this operation, 4870 MB of additional disk space will be used.

Всё равно на 700 пакетов больше, чем у арча, общий объем при этом меньше, то есть очень высокая гранулярность.

И что такое страшное произойдёт, если я прерву этот процесс вырубанием питания?

Файлы будут в неконсистентном состоянии.

Он тормозит не сильнее, чем распаковка .tar.gz архива на ext4. Было бы странным ждать большей скорости обработки данных.

Ты совсем тупой что ли? В саммари исследования белым по черному написано, что в одинаковых условиях dpkg тормозит более чем в пять раз по сравнению с pacman. У dpkg и распаковка медленнее, и ворох баш-скриптов тоже всё затормаживает. Хрен знает, что он еще там делает.

Ты читать умеешь вообще?

Еще раз повторяю, что мы сравниваем: Гранулярность разбиения примерно одного набора софта; Длительность деструктивной фазы работы пакетного менеджера с fsync и без.

Какой то сферический конь в вакууме. Ты утверждаешь что пакман распаковал 5+ гб архивированных данных в 5 раз быстрее? Допустим так оно и есть. Это значит он ставил пакеты в паралельном режиме - как минимум. Какую ересь он при этом он творил с индексными файлами пакетной системы я хз. На фоне этого вопрос «а что произойдёт если дёрнуть рубильник?» и «какова длительность деструктивной стадии?» действительно становится очень актуальным.

Мне в целом насрать насколько долго dpkg ставит пакеты (хотя rpm в Альте неприлично медленней dpkg), я знаю что если 2-3% действительно критичных файлов не будут убиты сбоем - система восстановится не слишком сложной переустановкой повреждённых (или всех если надо) пакетов. Я ДЕЛАЛ это на практике, потому что у меня были прецеденты (НЕСКОЛЬКО) рубильника в процессе обновления/установки. В т.ч. при обновлении дебиан6 -> дебиан7, что вообще то не следовало начинать в принципе, они вроде именно там внедрили мультиархитектуру. Но после рубильника процесс был возобновлён, пакеты починены, система обновлена и достаточно рабочей (насколько она могла быть рабочей с кривой мультиархитектурой).

Файлы будут в неконсистентном состоянии.

Проблема часа на 2 максимум. Если очень очень сильно не повезёт - придётся грузиться с лайва и потратить 4-6 часов, в основном на чтение мануала по ручной установке и настройке загрузчика и ядра.

Хрен знает, что он еще там делает.

Не так уж много. Есть стадии перестроения некоторых индексов между установками пакетов. Но это очень важный вопрос надёжности.

Файлы будут в неконсистентном состоянии.

Некоторые люди в древнем говне мамонта подумали, и решили что системе было бы неплохо переживать подобные вещи. Они спроектировали систему, способную выжить с неконсистентными файлами ещё тогда, когда ext2 в принципе не могла обеспечить консистентности. Я так понимаю с твоей точки зрения это баг, который надо исправить? Не неконсистентность, а способность её пережить.

Какой то сферический конь в вакууме.

Это не сферический конь, а показатель, напрямую влияющий на надежность. Я объяснял, почему: любые операции над файлами могут привести к неконсистентности при внешнем сбое. Отсюда следует, что эта стадия должна быть максимально быстрой. Чем быстрее пролетишь - тем меньше вероятность, что в момент этой стадии произойдет сбой, и тем целее будут файлы.

Это значит он ставил пакеты в паралельном режиме - как минимум. Какую ересь он при этом он творил с индексными файлами пакетной системы я хз.

Ты занимаешься гаданием на кофейной гуще, как с journald. Нет, пакман ставит всё строго последовательно. Просто написан нормально и с применением мозга, а не по логике «медленно и вдумчиво - значит надежно».

На фоне этого вопрос «а что произойдёт если дёрнуть рубильник?» и «какова длительность деструктивной стадии?» действительно становится очень актуальным.

Да, черт возьми, действительно. И это показывает, что поведение dpkg сильно хуже, потому что увеличивает вероятность отказа.

Мне в целом насрать насколько долго dpkg ставит пакеты

А не должно быть.

Проблема часа на 2 максимум. Если очень очень сильно не повезёт - придётся грузиться с лайва и потратить 4-6 часов, в основном на чтение мануала по ручной установке и настройке загрузчика и ядра.

Ну началось виляние жопой. Весь срач начался с того, что местный дурачок имел глупость сказать, что синхронная запись dpkg это надежно, и вот взрослый пакетный менеджер - это до-о-о-о… Что очень быстро рассыпалось об эксперимент и нехитрые подсчеты.

А теперь ты мне говоришь «ну и пофигу, что развалится, все равно можно починить». Вы определитесь, у вас надежно, или все-таки пофигу? Потому что в арче так-то тоже починить недолго, даже быстрее - тупо переустановить все пакеты по спику. Но в арче эта проблема вообще может не возникнуть, потому что пакеты ставятся быстро.

Не так уж много. Есть стадии перестроения некоторых индексов между установками пакетов. Но это очень важный вопрос надёжности.

Вот и разберись, почему dpkg тормозит. Как перестанет - можно будет поговорить о надежности.

Некоторые люди в древнем говне мамонта подумали, и решили что системе было бы неплохо переживать подобные вещи. Они спроектировали систему, способную выжить с неконсистентными файлами ещё тогда, когда ext2 в принципе не могла обеспечить консистентности. Я так понимаю с твоей точки зрения это баг, который надо исправить? Не неконсистентность, а способность её пережить.

Я тебе одну такую вещь скажу, ты только не пугайся. Даже ext4 не обеспечивает файловую консистентность, это тебе к btrfs и снапшотам. И вообще, сейчас 2024 год, ext4 уже 18 лет, и все (или почти все, по крайней мере серверные и десктопные) линуксовые файловые системы давно журналируемые, так что сбой питания для них не страшен. Вот собственно с момента появления журнала и надо было пересмотреть дефолтное поведение пакмана, потому что оно стало ухудшать надежность и увеличивать вероятность сбоя при установке.

А еще ты опять забыл, что dpkg даже с выключенным fsync тормозит как не в себя, что вообще херит на корню все разговоры о его надежности.

Отсюда следует, что эта стадия должна быть максимально быстрой

...или защиту можно реализовать на других уровнях.

Просто написан нормально и с применением мозга

Откладывая критически важные операции на «пока полсистемы не переустановится?». И что же тут может пойти не так? dpkg делает всё последовательно, близко к тому, как если бы ты ставил 450 раз по 1 пакету. Вероятно здесь зарыта разница в скорости, но это также гарантирует что повреждённым может быть 1 единственный пакет за раз, и то с вероятностью в ~70% не критично для его работоспособности. В системе довольно мало действительно критичных пакетов, так что с вероятностью 99,9% система выживает и несложно чинится.

Эмердж тоже так умеет. И ты вероятно в курсе насколько он долгий и тугой. Но проще убить Дракулу чем Генту.

И это показывает, что поведение dpkg сильно хуже, потому что увеличивает вероятность отказа.

Практика говорит о другом. Да и логика тоже. Какя часть времени установки пакета приходится на деструктивную стадию? Ну точно не та, в ходе которой обновляется man.db и кеш шрифтов.

А не должно быть.

Я же не втыкаю в роллинг. И у меня не винда, которой надо 2 ребута чтобы установить 1 обновление. Дебиан буквално делает обновления на живую, перезагружаешся потом, задним числом. Версии библиотек то в релизе не изменяются! Щанс сбоя менее 1%. Круче только Оракл - они ещё и гарантии всего этого предоставляют, но это уже за деньги.

Что очень быстро рассыпалось об эксперимент и нехитрые подсчеты.

Быстро =/= хорошо. Мне глубоко насрать на на консистентность файлов при обновлении. Я буквально по приколу могу дёрнуть рубильник, хотя за такое админа точно не по головке и не погладят.

Вы определитесь, у вас надежно, или все-таки пофигу?

А надёжность бывает только через атомарность и консистентность, или есть и другие варианты? Не слышал?

Как перестанет - можно будет поговорить о надежности.

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

Практика говорит о другом. Да и логика тоже.

Я сдаюсь. Объясняешь, показываешь, приводишь примеры - что в лоб, что по лбу. Ты даже контекст на два сообщения не можешь удержать. Я будто с табуреткой общаюсь.

Хрен с тобой, оставайся наедине со своими заблуждениями.

Что документация дебиана - говно. Спасибо, я и так в курсе.

И снова просто высер в воздух в ответ на аргументированный комментарий, без даже попытки хоть что-то возразить в ответ… Клоунада вышла на новый, доселе недостижимый уровень!

Ответ на твой вопрос есть в соответствующем issue: https://gitlab.archlinux.org/archlinux/packaging/packages/systemd/-/issues/24

Нихрена там нет. Пустая фраза «Design decision» без аргументации, почему именно было выбрано такое поведение, бесполезна.

По факту же имеем, что интеграция systemd в Arch не реализует стандартный механизм управления политикой.

Кто там ранее что-то вещал о том, какая плохая интеграция systemd в Debian, потому что видите ли вместо стандартного systemd-vconsole-setup продолжают использовать свой сервис, не напомнишь? – Ах да, «это другое»…

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

Он и не решает чужие проблемы, клоун, он старается максимизировать надёжность своей работы. Разумеется, с глючным железом он сделать ничего не в состоянии, однако есть то, что он сделать вполне может и что входит в его зону ответственности как приложения, осуществляющего непосредственную распаковку файлов. И dpkg это делает, и rpm это делает, и только школьные поделки являются «нетакусиками».

Твое мнение тут никого не интересует.

Ты у нас теперь ещё и мерилом общественного мнения сделался?

Циферки неутешительные (для дебиана), читай там выше

Ну да, ну да, давай сравним тёплое с мягким! В арчике даже initramfs не перегенерируется при установке KDE ЕМНИП – т.е. набор идущих в комплекте (по зависимостям) проектов совершенно разный. А для dpkg ты, небось, зачёл не только стадию распаковки (что только и делает pacman), но и последующую стадию настройки, да? Вместе с запуском сервисов, генерацией initrd, обновлением кеша шрифтов и проч.?

Ты собрался спорить с теорией вероятности, клоун?

Ты бы для начала выучил, как она называется, клоун.

Нет. Чем больше гранулярность - тем больше ручной работы. Эту ручную работу попытались решить с помощью лукапа по символам, и все равно до конца не решили.

Ручной работы особо не прибавилось бы даже при отсутствии автозаполнения зависимостей, поскольку в подавляющем большинстве случаев идёт замена одного имени большого пакета на одно имя пакета библиотеки, шедшей в том пакете. Т.е. вместо Depends: curl стало бы Depends: libcurl.

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

Что ты несешь, полоумный? Я вот буквально месяц назад делал чистую установку арча от минимальной системы до работающего KDE. Удивительно, но всё ограничилось установкой метапакетов, которые по зависимостям притянули всё остальное. Так что не надо тут врать.

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

Речь шла о попытках арча переехать на зависимости вида depends=(foo.so=4-64), которые, конечно, лучше, чем просто от имени пакета (хоть и не решают проблему на том уровне, на котором она решена в Debian), вот только использует их лишь малая часть репозитория, а большинство пакетов продолжают иметь что-то типа depends=(foo) в зависимостях.

Это и есть тот более примитивный вариант, о котором шла речь.

А я и не выдумываю. То, что ты отрицаешь реальность - исключительно твои проблемы. Я действительно всего лишь не хочу напрягаться ради неблагодарного юродивого с лора.

Верю! Настрочил уже неисчислимое количество простыней в ответ на мои сообщения – но сейчас вдруг не захотел напрягаться, по удивительному стечению обстоятельств.

Детский сад какой-то…

Совершенно не принципиально, что в более раннем обзорном каменте написано про форк

Ахахах! :D

И снова просто высер в воздух в ответ на аргументированный комментарий, без даже попытки хоть что-то возразить в ответ…

Ты очень самокритичен.

Нихрена там нет. Пустая фраза «Design decision» без аргументации, почему именно было выбрано такое поведение, бесполезна.

У тебя просто выборочная слепота:

So any presets which enable services by default aren’t enabled even if a preset would enable it. This sounds like a design decision, so not a bug. There are only three units enabled by default, and they’re specified in post_install() in systemd.install.

В арче в принципе не включают сервисы по-умолчанию, кроме трех исключительных, без которых ничего не работает вообще. Такая политика.

Ах да, «это другое»…

Да, моя радость, другое. Пресеты не используются, чтобы не нарушать политику невключения сервисов. Если тебе нужно включить сервисы - ну, просто включи их. А дебиановский костыль с консолью существует ради существования, как у куча других костылей. И я знаю как минимум один случай, в котором он работает хуже компонента systemd.

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

Однако, как мы, происходит ровно наоборот. Оверинжиниринг без анализа ситуации привел к проблемам.

Ты у нас теперь ещё и мерилом общественного мнения сделался?

Ну не тебя же им делать, право слово.

Ну да, ну да, давай сравним тёплое с мягким!

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

А для dpkg ты, небось, зачёл не только стадию распаковки (что только и делает pacman), но и последующую стадию настройки, да?

Пакман запускает пакетные хуки, неуч. Ты арч в глаза-то хоть видел? Похоже что нет.

Ты бы для начала выучил, как она называется, клоун.

По существу, клоун. Говори по существу, или молчи - умнее будешь казаться.

Ручной работы особо не прибавилось бы даже при отсутствии автозаполнения зависимостей

Гадание на кофейной гуще.

Автоматизация такого труда – это хорошо.

Хорошо. Особенно когда она работает ;)

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

Ути-пути, какие мы высокомерные :3

использует их лишь малая часть репозитория, а большинство пакетов продолжают иметь что-то типа depends=(foo) в зависимостях

Ты, видимо, вообще не понял, что я тебе пытался донести. Поясняю: даже при том, что этот механизм не использует вся пакетная база, зависимости работают очень хорошо. Что как бы намекает нам на его «нужность» в реялиях арча. Благодаря низкой степени гранулярности поломки случаются очень редко - не чаще, чем в дебиане. А ручная работа и так минимальна, потому что у пакетов редко меняются зависимости, благодаря той же гранулярности. При этом пакеты в апстриме пересобираются просто по именным зависимостям при изменении хотя бы одного.

Верю! Настрочил уже неисчислимое количество простыней в ответ на мои сообщения – но сейчас вдруг не захотел напрягаться, по удивительному стечению обстоятельств.

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

Ахахах! :D

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

В общем, с тобой всё понятно. Я совершенно напрасно надеялся на хоть какую-то рефлексию с твоей стороны. Объемы твоего бреда и копролалии бьют все мыслимые рекорды.

Ты очень самокритичен.

Эх, ты уже даже не стараешься. :( Несмешная клоунада с ответами вида «высер в воздух» уже поднадоела, честное слово.

Вот ты всерьёз считаешь, что на моё объяснение, почему документация находится там, где находится, отвечать высером «документация дебиана говно» – это аргументированный, достойный ответ?

В арче в принципе не включают сервисы по-умолчанию, кроме трех исключительных, без которых ничего не работает вообще. Такая политика.

И что помешало разработчикам арча просто предоставить дефолтный пресет disable *, как это делает тот же RedHat, и соблюсти свою политику по умолчанию, оставив при этом возможность выбора её поменять локальному пользователю?

Пресеты не используются, чтобы не нарушать политику невключения сервисов

Использование пресетов никак не помешало бы политике невключения сервисов – см. выше. Зато дало бы свободу пользователю поменять это поведение хоть для отдельных сервисов, хоть для всех сразу.

Вместо этого разработчики арча просто зафорсили свою политику на всех пользователей, лишив их стандартного инструмента из состава systemd, для этого и разработанного.

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

Ты у нас теперь ещё и мерилом общественного мнения сделался?

Ну не тебя же им делать, право слово.

Такой примитивный перевод стрелок… В отличие от тебя, я не пытался говорить за всех.

Гадание на кофейной гуще.

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

Хорошо. Особенно когда она работает ;)

Для библиотек – что является с отрывом самым распространённым видом зависимостей – прекрасно работает.

Скрипты ещё анализировать не научились, да, но это не повод сидеть на жопе ровно и не делать вообще ничего для повышения автоматизации труда мейнтейнеров.

Поясняю: даже при том, что этот механизм не использует вся пакетная база, зависимости работают очень хорошо. Что как бы намекает нам на его «нужность» в реялиях арча

Это какие-то ни на чём не основанные фантазии. Примеров проявления конкретно этой проблемы – просто завались.

Благодаря низкой степени гранулярности поломки случаются очень редко - не чаще, чем в дебиане.

И статистика у вас на этот счёт, конечно же, есть, и совсем не из разряда «одна бабка сказала», да? Ведь да?

Раз написано в 2016, что апстрим - так он до сих пор апстримом и остался

Всё пытаешься подменить тему. Сама ветка обсуждения как раз и началась с твоего заявления, что пакет rng-tools5 является «не апстримным форком». Тебе были предоставлены факты, что пакет взят из тогдашнего апстрима и форком не является. И теперь ты пытаешься съехать на то, что пакет ветки 5 не взят из текущего апстрима ветки 6 – ну надо же, кто бы мог подумать, лол! Однако это никак не меняет то, что «неапстримным форком» этот пакет не является.

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

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

Нет ты. ©

Я больше не буду тебе отвечать. Не в коня корм, клоун.

Печально видеть, как человек, 15 лет назад выпертый на мороз из модераторов тогдашнего LinuxForum за постоянные наезды и хамство, и который был абсолютно глух к попыткам всего модераторского состава как-то урезонить и достучаться, ища недостатки во всех кроме себя и настроив против себя даже извечных своих защитников, – остался таким же высокомерным хамовитым клоуном. Воистину, иногда возраст приходит один.

Доступен механизм значительного повышения надёжности в применимых системах, не требующий существенных ресурсов на реализацию

Это не механизм значительного повышения надёжности, это сраный карго-культ.

Если у тебя обновление прерывается посередине — то ты получаешь неконсистентное состояние системы, точка. То, что оно теперь на уровне отдельных файлов, погоды вообще не делает: ты точно так же теряешь любую возможность что-то гарантировать. Зачем тратить машинное время на лишние действия, которые в глобальном смысле ничего не решают, а только увеличивают суммарную вероятность отказа на порядок (потому что эта срань ТОРМОЗИТ как не в себя, кек)?

Я знаю, зачем: потому что доебан — это проект из 90-х, когда за каждым терминалом был бородатый админ, который после такого сбоя может загрузиться в single user mode, мастерски лавируя между не запускающимися из-за отсутствия библиотек бинарями, и с помощью бизибокса и такой-то матери всё починить. Но за окном 2024-й, и современные системы так не обслуживаются. Если тебе нужны гарантии атомарности, ты используешь или A/B, или снапшоты, или хотя бы полноценно транзакционные обновления, как в yum/dnf. Ни того, ни другого, ни третьего в доебане нет.

Ох лол. Нет, ради такого я все-таки отвечу.

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

Во-первых, не жалуйся на то, что с тобой тут как-то не так обращаются, потому что первым перешел на личности именно ты, предварительно поставив мне клоуна:

На вашу же клоунаду возражений, действительно, нет, тут только к доктору.

Не нравится? Учись общаться нормально.

А во-вторых - вау, у меня есть целый личный хейтер, который помнит какие-то срачи 15-летней давности с моим участием. Правда, помним мы их по-разному - в том числе и мои друзья, оставшиеся с линуксфорума. Дай бог встретимся с ними ИРЛ в следующий раз - расскажу о тебе, посмеемся.

Ладно, на самом деле вряд ли. У нас и так будет что вспомнить более ценного, чем какого-то буйного фанатика с лора.

Если у тебя обновление прерывается посередине — то ты получаешь неконсистентное состояние системы, точка

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

Изначальное утверждение: «Использование механизмов fsync() + rename() позволяет повысить надёжность (т.е. снизить риски)».

Утверждение, которые вы опровергли: «Использование механизмов fsync() + rename() позволяет гарантировать консистентное состояние всей системы».

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

Если в случае A мы имеем вероятность наступления события критической аварии P1, а в случае B – P1 + P2, где P2 >> 0, то вероятностная мера up(А) < up(B). Таким образом, надёжность системы А выше, чем системы B.

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

доебан

О, прошу прощения, когда я писал вам свой ответ, этого ещё не было, и я принял вас за адеквата. Признаю свою ошибку.

Всего вам хорошего.

первым перешел на личности именно ты, предварительно поставив мне клоуна

А не надо было в ответ на абсолютно нормальный вопрос писать про закапывание Debian и проч. Это клоунада и есть.

А во-вторых - вау, у меня есть целый личный хейтер, который помнит какие-то срачи 15-летней давности с моим участием.

Увы, я страдаю огромным недостатком: хорошей памятью. А учитывая, что то обсуждение я наблюдал лично, вспомнить было несложно.

Дай бог встретимся с ними ИРЛ в следующий раз - расскажу о тебе, посмеемся.

Передавай привет. :)