С кем я там срался полгода назад по поводу dpkg vs pacman?

Пакман и Арч может. В том и дело. А Дебьян не может. Только в исключительных редких случаях, когда от пакета больше никто не зависит. Прошёл я школу Дебьяна, от корочки до корочки. Всё. Хватит.

pacman --print-format=${format}. Мощная штука.

Busybox на целевой системе, куда ставится дистрибутив? Нафига? В ArchISO есть всë необходимое для установки системы, любые локальные физические носители не нужны. Но при необходимости можно и с физического носителя поставиться.

А что, в Debian нет виртуальных пакетов?

И ещё камень в огород твоей «критической зоны»… Что то не вижу никакого превосходства - всё упёрлось в диск и никаких чудес не произошло.

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

Ты точно уверен, что твоё «низкое время в критической зоне» не является быстрым дисковым кешем

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

дружелюбный пользователю

Он не user friendly, а user centric. Хочешь шрифт в консоли поменять? Вот те команда. Не хочешь команду, правь сам, руками, там-то. Подстилание соломки в обязанности Arch-a не входит :)

Ложь.

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

Главный признак фанатиков - они хотят пообъяснять как жить.

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

Пруфы, чукча.

Весь тред - один сплошной пруф.

тот который лучше всех работает.

Правильно. А лучше всех работает поддерживаемое разрабами и дистростроителями решение. Которое ты по причине своей тупости и замшелости не выбрал, а выбрал груб1.

--help же.

А у меня диаметрально противоположно получилось. Сначала стабильная слака, потом -current, и вот теперь разрываюсь между арчëм и слакой :) Одновременно два дистра одминю :)

Почему же? Можно ссылку на то место в вики, где про это сказано?

Вероятно, это такой тест на «профпригодность» :)

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

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

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

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

И не существует никакой разумной причины чтобы команда из 3 слов превращалась в такой геморрой.

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

Кстати, ты можешь замерить дисковую активность и посмотреть, сколько диска действительно ест запись каких-то сотен байт или пары килобайт за раз. Спойлер - мало. А еще посмотреть, сколько объема - тоже настолько мало, что заморачиваться смысла нет даже если ты используешь SSD/NVME: достаточно посмотреть минимальное количество циклов перезаписи ячейки, прикинуть количество ячеек на диске, вспомнить, что контроллир ротирует их и расслабиться. Ты никогда не выработаешь логами десктопа их ресурс.

преимущества журналда были неочевидны

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

Теперь у них комплексы

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

Да, именно. И это инструмент systemctl который применяет команду disable на сущность journalctl.service.

Нет. Ты не понимаешь, что такое disable. Disable убирает симлинку из автозапуска, и больше не делает ничего. Сервис может быть запущен по другой причине, и чтобы явно запретить его запуск, нужно использовать mask, причем как на сервисе, так и на сокете сервиса. В случае с журналом это тоже сработает, скорее всего.

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

Просто дайте мне молоток и не надо стоять за спиной и мешать мне колотить по яйцам если я так решу. Это единственный адекватный способ делать инструменты.

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

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

Что я подтвердил, дуралей? Меряли время установки, от начала записи пакетов и исполнения скриптов, до их конца. Включи уже голову, господи.

Зато результаты работы намного целее.

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

И поэтому по настоящему критичеескими являются моменты изменения статуса юзермпейсных моментов в БД пакетов и файловые операции на дкритическими системными компонентами

Нет. Критическими являются моменты неконсистентности софта.

В моей башке существует простой вопрос: Это удобно? Это полезно? Мне это надо?

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

Что лучше, написать строчку в онфиге

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

kirill_rrr in a nutshell:

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

— ЛОР, а почему я суп так медленно ем? И мне очень неудобно.
— Потому что ты ножом суп ешь? Ложкой ешь.
— Ложкофанатики не нужны! Еще варианты?
— Ну отхлебни из тарелки тогда.

— ЛОР, почему на меня в ресторане так странно поглядывают?
— Потому что ты с ножа ешь!
— Каждый раз одно и то же, что за дебильные фанбои. А другого объяснения нет?
— Может и есть, но это не важно. Важно есть твердое вилкой, а жидкое ложкой.
— У меня уже есть нож, зачем мне нужна ложка?

— ЛОР! Мне так больно, у меня кровь течет! За что мне это?
— Чем суп ел, дебилушка?
— Ножом, конечно.
— А ложку не пробовал взять?
— Зачем мне ложка, если я могу отломать половину ножа и затупить оставшееся, чтобы была безопасная плоскость для поедания супа?
— Она всё еще острая и суп в нее не зачерпнешь.
— ВОТ ВИДИШЬ КАКИЕ РАЗРАБЫ НОЖА ИДИОТЫ?!

Не удержался: https://packages.debian.org/sid/grub-legacy

зависимости
рекомендации
предложения
enhances
dep: grub-pc (>= 2.12-4)
системный загрузчик GRUB, версия 2 (вариант для PC/BIOS)

Это в Debian Sid, то есть, в следующем релизе grub-legacy дропнут.

https://packages.debian.org/bookworm/grub-legacy

Заметим, что в GRUB Legacy только исправляются найденные ошибки, а новые возможности добавляются только в GRUB 2 (пакет grub-pc).

Даже более того, apt благодаря шаблонам поиска позволяет выполнять операции по весьма сложным условиям, например «все установленные автоматически (по зависимостям) пакеты архитектуры armhf, собранные из такого-то пакета исходного кода и установленные из указанного репозитория».

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

по зависимостям

Кстати, я тут написал о серии постов о новом «solver3».

APT 2.9.3 introduces the first iteration of the new solver codenamed solver3, and now available with the –solver 3.0 option. The new solver works fundamentally different from the old one.

У меня «apt 3.0.0devuan1», но что-то я не понял, как использовать эту опцию –solver.
Или же в 3.0.0 она стала по умолчанию, надо почитать.

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

Ты это прям с осуждением чот, прям с негодованием каким-то.

Потому что достали вот эти вот утята, которые не знают, но мнение имеют.

достали вот эти вот утята, которые не знают, но мнение имеют.

Так отойди от зеркала.

Вот с регэкспами да, pacman их не поддерживает.

Я солгал. В части поиска по части имени файла, чтобы определить, какому пакету принадлежит файл, можно сделать

sudo pacman --files --refresh
pacman --files --regex <кусок_имени_файла>

Я солгал.

Ошибка – не ложь. :)

Ну, во всяком случае, в 2013-м году на aptitude бочку катили:

2.2.1. apt vs. apt-get / apt-cache vs. aptitude

Although aptitude is a very nice interactive tool which the author mainly uses, you should know some cautionary facts:

The aptitude command is not recommended for the release-to-release system upgrade on the stable Debian system after the new release.
The use of "apt full-upgrade" or "apt-get dist-upgrade" is recommended for it. See Bug #411280.
The aptitude command sometimes suggests mass package removals for the system upgrade on the testing or unstable Debian system.
This situation has frightened many system administrators. Don't panic.
This seems to be caused mostly by the version skew among packages depended or recommended by a meta-package such as gnome-core.
This can be resolved by selecting "Cancel pending actions" in the aptitude command menu, exiting aptitude, and using "apt full-upgrade".

Это взято отсюда, и оно актуально для Debian Bookworm.

Есть ещё тема, которая как раз 13-м годом датирована, и там Rootlexx рассказывал о проблемах aptitude. Конечно, времени прошло много, что-то с тех пор изменилось, но это было. Интернет всё помнит :)

Ща aptitude вообще на удаление помечен.
https://tracker.debian.org/pkg/aptitude
И не факт что есть человек который это поправит

не грузится. его вручную нужно грузить до инитрамфс. это я читаю документацию увидел. а еще узнал, что через kernel-install можно записи для системд бут генерировать только это применимо примерно никак. в арче много чего «нестандартного»

Ну почему? Пи4 и Пи5 вполне себе десктопы.

Чтобы автогенератор конфига не затирал мои собственные настройки разумеется! Автогенератор конечно можно сконфигурироваать на что угодно, но недефлтные случаи делаются там довольно сложно, а lts-дистрибутивы можно обновлять 1 раз в 1-2 месяца, причём версия ядра не меняется, только патчи безопастности падают. Так что проще вообще не пускать автоконфигуратор в /boot и не огребать нежданчика после ребута. Также эта политика отлично сочетается с самосборными ядрами, а я с 2010 до 2020 сидел на них.

но это не то, о чём гласят все документации для Дебьяна.

Именно это и рекомендуют инструкции по дебиану чтобы не «Посиди с ключиками dpkgпогрепай и полессай». Что за дикое желание делать хуже?

вылези из скорлупы и переосмысли и Дебьян и Арч

Чтобы что? Ты гарантируешь что Арч будет нормально работать 5-8 лет подряд обновляясь 1 раз в 2 месяца нажатием 18 кнопок на клавиатуре и генерируя менее 1 пробелмы в год? Каждый первый чел из интернета и с ЛОРа твердят что Арч не про это. Стоит ли им верить, или Арч - не LTS-дистр? А кто компенсирует мне время, потраченное на забывание всех навыков и обучение новым, точно таким же?

Да что там, даже о gui!!!

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

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

А так - это пук в лужу. Ну флешка и флешка.

Ну тормоза и тормоза... Ну полчаса в «критической зоне» и полчаса в «критической зоне»...

Платформа-то другая, не x86{,_64} :)

или Арч - не LTS-дистр?

This. А еще он rolling.

Ты гарантируешь что Арч будет нормально работать 5-8 лет подряд обновляясь

Арч-то нормально работает. Не работать могут сторонние драйвера, например, nvidia. Как и везде. Debian в этом плане исключением не является.

Ты не объяснил внятно

Насколько тугим надо быть чтобы не понять: Задача - не срать на диск. Задача - сделать отключение/включение 1 простой командой на уровне дефолтного управления демонами. Задача - выкинуть 1 лишний процесс и оперативки и процесса загрузки.

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

Это твои личные загоны «нет системы без логгера» и «нет поиска проблем без системы диагностики». Это не техническое, это к психиатору. А людям ИРЛ с раннего детства приходится искать и воспроизводить проблемы без системы логгирования ещё до того как они впервые увидят монитор и потрогаю клавиатуру. У нормальных людей с 20++ годами опыта предположительные причины сбоя всплывают в сознании автоматически, ещё до того как палец дотянется до 'j' чтобы наборать 'journalctl', и вот что странно - подсознание угадывает достаточно часто!

И к полезности журналда. Я тоже могу найти сбой с его помощью, причём даже не особо то умея пользоваться им. Возьмём то же самый арч/журналд/сддм/кде6.3/вайланд. Я ковыряюсь-ковыряюсь в настройках, много чего меняю, ребут, чёрный экран и нет сддм! Стандартный список попыткок запуска-перезапуска, ясное понимание что виновата новая конфигурация сддм, которую я накликал в настройках кде. Возможное решение проблемы - обнуление профиля. Жалко, долго, но сойдёт как план Ж. Сначала надо попробовать руками настроить конфиг в /etc/sddm*...

Потом я вспминаю что журналд что то там срёт на диск, решаю заглянуть. Читаю... ладно, довольно долго... Нифига не вижу никаких сбоев.. Обращает на себя внимание строчка «проблема с обработкой файла /адрес/файла/темы. Ок, есть предположение, отключаю тему в конфиге, проблема решена. Обрати внимание - настоящая причина не противоречила моему первому предположению и могла бы быть найдена и решена по предыдущему пути, причём не факт что не быстрее (в конфиге всего ~8 строк, виновата явно одна из них).

Что здесь не так? SDDM не выдавал никаких предупреждений об аварийном завершении или о сбое чего либо после фейла с темой, он просто продолжил работу и с его точки зрения корректно. Возможно ты в курсе как много предупреждений могут насрать qt- и gtk-приложения продолжая нормально работать. Формально, если выключить интуицию - в журнале нет никаких причин сбоя. Журнал не может совершить чуда, он сообщит тебе исключительно то, что туда положит проблемное приложение и никто никому не гарантииует что там будет нужная информация. К тому же журналд не уникален и не незаменим, я мог бы прочитать юнит sddm.service и просто выполнить команду из него, предварительно подняв его зависимости и увидеть в консоли всю ту же самую информацию.

Тебе объясняют, как сделать, чтобы было хорошо

Не ври. Я тебе объясняю как мне надо, а ты начиаешь рассказывать почему мне это не надо. Ничего про „как сделать“ и совершенно перпендикулярно к „хорошо“. Диалог должен был быть примерно таким: - Я не могу отключить журналд.
- Его не надо отключать
- Но он мне нахрен не нужен
- Ну тогда отключи его вот так: ... ... ...

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

А лучше всех работает поддерживаемое разрабами и дистростроителями решение.

Нет, лучше всего работает то решение, которое решает задачу лучше всех, ваш К.О. Мнение дистростроителей важно, но не обязательно.

Арч-то нормально работает.

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

В Arch максимум, что при постоянной версии ядра может обновиться – это initrd, но если используется GRUB2, необходимости переустанавливать или переконфигурировать загрузчик никакой нет.

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

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

Задача - не срать на диск

Логов не так и много:

$ du -haxd1 /var/log 2>/dev/null
1.1M	/var/log/wtmp.1
44K	/var/log/Xorg.0.log.old
4.0K	/var/log/old
44K	/var/log/Xorg.1.log.old
4.0K	/var/log/private
4.0K	/var/log/btmp.1
0	/var/log/dnscrypt-proxy
44K	/var/log/Xorg.1.log
2.9M	/var/log/pacman.log
4.0K	/var/log/audit
0	/var/log/README
4.0K	/var/log/lastlog
60K	/var/log/Xorg.0.log
0	/var/log/btmp
4.0K	/var/log/gssproxy
680K	/var/log/wtmp
12K	/var/log/journal
4.8M	/var/log

Основное место занимает кэш пакмана, поэтому иногда его вычищаю:

$ du -haxd1 /var/cache/pacman/
213M	/var/cache/pacman/pkg
213M	/var/cache/pacman/
$ sudo pacman -Scc

Cache directory: /var/cache/pacman/pkg/
:: Do you want to remove ALL files from cache? [y/N] y
removing all files from cache...

Database directory: /var/lib/pacman/
:: Do you want to remove unused repositories? [Y/n] 
removing unused sync repositories...

$ du -haxd1 /var/cache/pacman/
72K	/var/cache/pacman/pkg
76K	/var/cache/pacman/

И он за 5 лет

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

У меня было вот прям недавно, что телега из xfce-шной панели быстрого запуска не запускалась. Оказалось, имя бинарника поменялось. Панель и значки на ней создавал я, не скрипты, чинить пришлось тоже мне :) Но это в любом дистрибутиве случилось бы. Как и везде, проверяем самое простое и чиним за несколько секунд :)

Я телегу скачивал с оффсайта, т.е. не через пакетный менеджер. Там всего два файла Telegram и Updater, они ни разу не меняли названий. А вот desktop-файл по моему пересоздается при каждом запуске, а-ля org.telegram.desktop._3e485da34fc040f9218e3891ecde1e6c.desktop

Я телегу скачивал с оффсайта

А какой от этого профит? Официальный пакет же есть.

Ну тормоза и тормоза… Ну полчаса в «критической зоне» и полчаса в «критической зоне»…

Ты опять выдернул слова из контекста. Перечитай ответ еще раз.

Задача - не срать на диск.

Задача решается логгированием в память.

Задача - сделать отключение/включение 1 простой командой на уровне дефолтного управления демонами.

Нет такой задачи, как нет и «дефолтного» управления демонами. Systemctl соответствует той концепции, которая реализована в systemd. При этом оно не соответствует манямирку, который существует в твоей полупустой голове. Очевидно, тебе надо почитать ман и изучить наконец, чем disable отличается от mask.

Задача - выкинуть 1 лишний процесс и оперативки и процесса загрузки.

И снова нет такой задачи. Ресурсы надо освобождать по необходимости и не ради самого факта освобождения.

Это твои личные загоны «нет системы без логгера» и «нет поиска проблем без системы диагностики». Это не техническое, это к психиатору.

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

Во-вторых, журнал можно отключить путем маскировки. Но это никому не нужно.

А людям ИРЛ с раннего детства приходится искать и воспроизводить проблемы без системы логгирования ещё до того как они впервые увидят монитор и потрогаю клавиатуру.

Ты бредишь.

У нормальных людей с 20++ годами опыта предположительные причины сбоя всплывают в сознании автоматически

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

настоящая причина не противоречила моему первому предположению

Это называется «ошибка выжившего».

Не ври. Я тебе объясняю как мне надо, а ты начиаешь рассказывать почему мне это не надо

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

Но нет, „отключить журналд“ противоречит твоим догмам

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

Нет, лучше всего работает то решение, которое решает задачу лучше всех, ваш К.О. Мнение дистростроителей важно, но не обязательно.

Нет. В концепции systemd лучше всего работает решение, предусмотренное разработчиками systemd. Дистростроители тут совершенно ни при чем.

Там дофига зависимостей, а тут один файл. Мне все вот эти qt6 вообще не нужны.

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

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

Разумная причина в том, что почти никому на этой планете не нужно отключение логов на серверах и рабочих станциях.

Где из этого следует необходимость поломать невключение логов?

И ты не прав - на смартфонах, роутерах и IoT никому не нужны логи. И поэтому там нигде нет системд, хотя он мог бы там помочь. Но один только этот идиоский хак с писанием лога в оперативку и непрерывным ротированием уничтожает возможность запихать системд на мой роутер с 48Мб оперативки (и все милиарды таких роутеров).

А у тебя обычный десктоп, и для обычного десктопа отлично подойдут дефолты.

Л

Ложь для 3/4 моих устройств с линуксом.

Кстати, ты можешь замерить дисковую активн

Лучше скажи сколько транзакций на флеш-память делают 10000 сообщений по 50 байт в течении суток если физичексий чанк диска например 64Кб а время коммита фс стандартное?

Но как я уже говорил, у меня есть диски, очень чувствительные к многопоточному чтению-записи и вот что странно, эти строчки в журнал почему то генерируются тогда, когда диск должен быть свободен для чего то другого. быть или не быть трешингу, вот в чём вопрос! И почему юсб2.0 микроСД работает быстрее юсб3-флешки, хотя физически всё наоборот. И если я не вижу проблемы на большом ссд - это не значит что её там нет.

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

Если ты не забыл расставить метки в текстовых логах, то они расставлены точно так же. И тебе точно так же надо или деражть ВСЁ в оперативке, или пробежаться по всему файлу реагируя на метки. Примерно ноль разницы. Гигабайт текстового лога грепается за время чтения диска точно так же как гигабайт бинарного. Индексация? Значит будет оверхед и проблемы с обслуживанием, а главное - надёжностью системы логгирования. Фееричная идея, в топку.

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

Это весьма продвинуто и совершенно! Особенно когда использование mask ломает зависимости (которые контролируются вообще? Или давай ребут, а там посмотрим что отвалится!), а инструмент собственно отключения демона он где? Не удаления юнита из списка юнитов, а отключение - почувствуй разницу. Или вот ещё вопрос: а зачем собственно юнит обязательному процессу, без которого вообще никак нельзя? У тебя же нет юнита дял init и для самого системд, зачем для журналда? Или если в системд встроено управление cgrops то почему автоматически не создаётся сокет журнала, зачем выделять отдельного демона?

Я вообще то могу распознать примитивное решение, где стоит что то тронуть и что то идёт не так когда увижу. Это оно самое.

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

В чём проблема сделать вообще не писать? Это сложно? Это тратит ресурсы? Это требует мозга от разработчика? Может быть для этого хоть что то надо делать?

Разработчики придумали инструмент для определенной задачи

И он не только не нуже, но и мешается. Ну примерно как компрессор в багажнике легковушки. Кому то нужен, комуто нет. Кто то найдёт более разумное применение освободившемуся месту.

Что я подтвердил, дуралей?

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

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

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

Критическими являются моменты неконсистентности софта.

Фанатик.

Ответ - да.

Ответ - тебя не справшивали, я всё без тебя сделал и уведомил о результате.

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

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

Ну так это будет ещё лет через 5...