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

Ты что-то не то читаешь.

А вот это станет жопой для дебиана. Синаптик не вывезет, к тому же он ГУЙёвый.

Разумеется есть как только у тебя появляется А/В конфигурация или самосборное/стороннее ядро с экспериментальными версиями. И я бы вообще хотел иметь возможность грузиться без initrd так же просто как с ним.

mkinitcpio and dracut generate combined initramfs files by default

Гном3+/гтк и файерфокс довольно доходчиво мне объяснили что проблема будет вылезать чаще чем раз в полгода. Да и с генту я слез потому что роллинг находится в состоянии перманентного крушения юзеркейсов.

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

Всё в твоих руках: собираешь ядро, включаешь модули для файловой системы твоего корня в него, и вуаля.

Ах, да, в слаке, например, huge ядро есть. Да, оно жирное, но оно может грузиться без initrd на широком спектре железных сетапов. Это так, к слову. На самом деле слакварщики или на самосборных ядрах сидят, или на дистрибутивном generic. Но ему уже initrd нужен. Я предпочёл второй вариант. В арче же использование initrd – это официально поддерживаемый сетап.

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

Ну, у меня он с момента установки накидал 49Мб а это порядка милиона записей.

Второе не требует никаких дополнительных усилий и не создаёт проблем. Всё уже 20 лет как подстроено.

Если это что то будет иметь какие то последствия для меня - я их увижу.

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

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

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

И ты не прав - на смартфонах, роутерах и IoT никому не нужны логи.

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

уничтожает возможность запихать системд на мой роутер с 48Мб оперативки

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

Но если тебе нужно 48 мегабайт кровь из носу - возьми классический init и не мучайся.

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

У тебя планировщик настроен через жопу. Изучи, как в линуксе устроена запись на диски.

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

Флешка дерьмовая.

Если ты не забыл расставить метки в текстовых логах, то они расставлены точно так же.

О каких метках идет речь, уточни?

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

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

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

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

которые контролируются вообще?

Если бы ты прочитал маны по systemd, то ты бы это знал.

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

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

В чём проблема сделать вообще не писать?

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

И он не только не нуже, но и мешается.

Он не мешается, просто ты не понимаешь, зачем он нужен.

Очевидно то, что не углублялся в процесс установки пакета

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

Тебе молиться на консистентность или работать?

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

Фанатик.

Возвращайся в школу, неуч.

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

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

А то что цель не достигнута - да кого это интересует, ведь в журнае то записано что всё ОК!

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

Очевидно, тебе надо почитать ман и изучить наконец, чем disable отличается от mask.

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

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

И снова нет такой задачи.

Ну вот я её поставил и она проще некуда... В нормальной системе!

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

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

это объективная реальность

В объективной реальности линукс без журналда работает точно так же как с журналдом и мир от этого не рухнул.

Логгирование нужно практически всегда,

...когда руки из жопы у всех.

Когда ты двадцать лет эникеишь на дебиане - конечно, ты выучишь типовые проблемы наизусть

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

Собственно, в попытке поставить арч ты тоже поплыл

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

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

Этому новому инструменту сколько вообще лет? С каких грибов ты решил, что я его не умею использовать? Не использовал? Не сравнил в подробностях инструмент А и инструмент Б? Не описал во всех подробностях почему именно Б лучше чем А и в каких конкретно задачах для меня это важно?

Потому что ты идиот и хочешь неправильного.

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

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

И она статистически повторяется сотни раз в неделю? Это какая же у меня удача?

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

А выходить на улицу без светоотражающего жёлтого или оражевого жилета, шлема, наколенников, налокотников, защиты позвоночника, бронежилета, респиратора, презерваива и газового балончика/электрошокера противоречит бестпактикам ОБЖ. Начни соблюдать технику безопастности!

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

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

Отбой тревоги, пометку на удаление убрали

Всё уже 20 лет как подстроено.

Не. Демьянщики уже 20 лет как выдрессированы, что когда релизится софт - это не для них.

Причём пробелмы приходилось решать на таком раннем этапе, где журналда не было!

То есть, где? На установочном носителе? Так от там есть, но сконфигурирован с учетом того, что он запускается из временной среды:

When journal namespacing (see LogNamespace= in systemd.exec(5)) is used, setting Storage= to «volatile» or «auto» will not have an effect on the creation of the per-namespace logs directory in /var/log/journal/, as the systemd-journald@.service service file by default carries LogsDirectory=. To turn that off, add a unit file drop-in file that sets LogsDirectory= to an empty string.

Note that per-user journal files are not supported unless persistent storage is enabled, thus making journalctl –user unavailable.

The storage to use can also be specified via the «journal.storage» credential. Values configured via configuration files take priority over values configured via the credential.

Added in version 186.

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

Здоров.

В этом проблема системд. Они создали свой собственный манямирок и насильно запихали туда всех остальных.

Systemd реализовали изменения, которые требовались современным линуксам. Задачи, которые решаются в ОС, стали сложнее, поэтому и система управления тоже усложнилась и появились новые концепции.

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

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

Ну вот я её поставил

Не поставил, всё еще нет такой задачи. Есть извращения, которыми ты занимаешься - это да. Но не задачи.

В попытке поставить арч я его поставил

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

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

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

Этому новому инструменту сколько вообще лет? С каких грибов ты решил, что я его не умею использовать?

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

Начни соблюдать технику безопастности!

Хорошо. Сразу после того, как ты начнешь носить главный элемент своей спецодежды - клоунский нос. Договорились?

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

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

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

Почему все старательно игнорируют существование Storage=none? Не говоря уж о том факте, что право дрочить вприсядку не может быть ограничено никаким дистрибутивом даже теоретически.

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

It is the default init system for Debian since Debian 8 («jessie»)

Но ты ведь используешь дистрибутив, в котором systemd по умолчанию. Если тебе не нужен systemd, почему не сидишь на Devuan, почему пробовал именно Arch, а не Artix? Впрочем, в Arch тоже можно поменять init на openRC, но в этом случае тебе придётся писать все необходимые сервисы самому.

Потому что ТС начнет верещать, что это не отключение, а отправка в /dev/null, и журнал все равно будет работать.

Когда наступают последствия, обычно что-то делать уже поздно.

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

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

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

К тому же если у тебя не расстреляли на месте и появилась возможность расследовать причину сбоя - всегда можно включить логгирование и воспроизвести ситуацию. Если сбой плавающий - просто оставь логгер работающим до того момента когда ситуация повторится. Если ты в жёстком энтерпрайзе - разве я предлагал тебе отключать логгер в жёстеом энтерпрайзе? Так что ты не в жёстком энтерпрайзе и твоё драгоценное время не стоит по 1000$ за секунду а сбой и простой не стоит практически ничего. Уж точно меньше чем все эти извращения с мониторингом логов в реалтайме, без которых журналд не нужен.

Нет никакой техничесокй причины не ставить минимум 256 мегабайт памяти

Зато есть экономическая - бессмысленные траты бессмысленны. И кстати для системд 256М тоже слишком мало. И вообще никто не ставит системд+журналд на роутер.

У тебя планировщик настроен через жопу. Изучи, как в линуксе устроена запись на диски.

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

О каких метках идет речь, уточни?

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

Нет, это работает через быстрый бинарный поиск по дереву

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

Есть всего один вариант, когда дерево будет оптимальнее - когда вместо него произошла сортировка в несколько линеек, причём способ сортировки 100% соответствует запросу пользователя. А значит система изначально однозадачная и абсолютно не гибкая.

Тебе не надо пробегаться по всему файлу, достаточно использовать seek()

Что тебе мешает выставить метку seek() в заголовке строки в линейном логе текстового формата? Это если бы мы были в 1990-х с медленными дисками и второпнём, для которого поиск подстроки в мегабайте текста это больше милисекунды. Но мы нет. А ещё у нас есть многоядерные процессоры, а задача вообще то легко паралелится и упирается в скорость линейного чтения диска.

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

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

Все бинарные базы так работают, кретин.

Ты же абзацем выше утверждал что они работаю быстрее диска!

Если бы ты прочитал маны по systemd, то ты бы это знал.

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

Ты не в состоянии осознать, что логи выключать вообще не нужно,

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

Он не мешается

Ложь.

Зато про усталый диск не сможет. А мы еще что-нибудь придумаем. Например, отключим журнал на арче и скажем «А ВОТ».

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

который быстро работает и минимизирует вароятность сбоя.

ИЛИ быстро работает, ИЛИ минимизирует вероятность сбоя.

Ты даже сделать нормально не осилил

Ложь. У меня реализована самая оптимальная загрузка для экспериментальной биос-совместимой железки под 1 дистрибутив.

Так ты просто сам себе создаешь проблему

Какую?

Уф...

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

Передергиваешь. Отклонить.

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

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

всегда можно включить логгирование и воспроизвести ситуацию

Нельзя. Плавающие глюки так не воспроизвести.

просто оставь логгер работающим до того момента когда ситуация повторится

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

Так что ты не в жёстком энтерпрайзе и твоё драгоценное время не стоит по 1000$ за секунду а сбой и простой не стоит практически ничего.

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

Планировщик дефолтный арчевский.

Значит никаких проблем с диском нет.

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

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

Что тебе мешает выставить метку seek() в заголовке строки в линейном логе текстового формата?

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

Ну так это не далеко ушло от сислога или логротэйта.

Еще раз: ты понимаешь, как работает хотя бы двоичный поиск?

Ты же абзацем выше утверждал что они работаю быстрее диска!

Поиск по структурированной базе работает быстрее, чем линейное чтение по диску. И?

И что в мане написано про случай, когда системд не уведомляет что у маскируемого юнита есть зависимости?

Чтение манов в слух - $500 в час. Я и так битые 10 страниц пытаюсь бесплатно повысить уровень твоего образования, но не в коня корм.

Ты не в состоянии понять, что дело вообще не в логах.

Нет, клоун. Проблема в том, что ты просто хочешь отключить логи, абы было, и твоей фанатичной уверенности, что ТАК НАДО.

Ты даже не попытался изучить структуру операций

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

А теперь ты занимаешься тем, что отрицаешь реальность.

ИЛИ быстро работает, ИЛИ минимизирует вероятность сбоя.

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

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

всегда можно включить логгирование и воспроизвести ситуацию.

Жизнь куда более сложная штука, чем кажется. И она иногда выкладывает такие фортели, что мама не горюй. Ладно, тут речь про софт, софтовую неисправность можно исхитриться и поймать, хоть и далеко не всегда, но вот с железом и с железно-софтовой системой это уже куда сложнее. Ладно если это какой-нибудь утюг, у которого неисправность – то работает, то не работает, и то, далеко не сразу найдёшь, что неисправность в обломившемся у вилки сетевом кабеле, и то, это не единственная возможная проблема. А если это какое-то более сложное устройство, у которого проблема «не работает», а привозят в сервис и оно «чудесным» образом начинает работать? А уж с компами, которые как раз и есть «сложный программно-аппаратный комплекс»? Нет уж, мне не жалко 10 МиБ места под логи.

Это на винде не смотрят в логи

В смысле «не смотрят»? Сфигали? Очень даже смотрят)

И ты не прав - на смартфонах, роутерах и IoT никому не нужны логи.

На роутерах не нужны логи?

https://jcutrer.com/howto/networking/mikrotik/persistent-logging-to-disk

Жаль, у MikroTik не было своего kirill_rrr, чтобы им всё объяснить.

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

Вы туда руками что-ли лезете? DO NOT EDIT THIS FILE для кого там существует? Или /etc/default/grub для вас «кошмарный и геморройный конфиг»?

Да херня все эти ваши DO NOT EDIT THIS FILE.

У меня стоит несколько ОС на ноуте. Grub вынесен на отдельный раздел. Конфиг к нему написан вручную. Из этого конфига уже инклудятся те самые конфиги конкретных ОС, которые DO NOT EDIT THIS FILE.

Выглядит это примерно так:

menuentry "Arch" {
    set root=(lvm/aq-aq_archlinux)
    configfile /boot/grub/grub.cfg
}

menuentry "Artix" {
    set root=(lvm/aq-aq_artix)
    configfile /boot/grub/grub.cfg
}

menuentry "Rosa" {
    set root=(lvm/aq-aq_rosa)
    configfile /boot/grub2/grub.cfg
}

В целом этот grub2 простой как два пальца.

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

Потому что у арча в этом не было необходимости никогда. И GUI-шные тоже не нужны по сути.

pacman простой и удобный как ложка для супа.

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

Да он баш-портянки в /etc/grub.d/ осилить не смог. А пользуется grub-legacy. Чего, кстати, в нём такого, чего нету в lilo, раз уж на то пошло? Lilo ведь, пожалуй, самый простой загрузчик из всех имеющихся.

(только про –cascade ему не говори, ок?) :)

Ахаха))

Мой любимый способ удалять пакеты - pacman -Rscn и смотреть, сколько предложит снести.

Но можно и круче – pacman -Rsscddn :) Вот это реально может делов наделать :)

Политика дробления может быть и такой, как в Slackware: один пакет = одна программа, там в целом это так и есть, за некоторыми исключениями (gcc, Xorg, KDE и, возможно, еще что-то). Но там ПМ медленный, поскольку написан на bash, да еще и плагин slackpkg+ – более 2700 строк.

Да я просто хотел бы чтобы пакетник при поиске не выдавал кучу строчек с описанием пакетов

pacman --sync --search --quiet

выдавал метку статуса пакета

pacman --sync --search --print-format='%n (%v -%l)'

Эх, если б да кабы, да во рту росли грибы логи были б не нужны, да не было б этой проги :-)

А nm просто отсутствует на лайв-установщике.

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

Все новое кажется кривым и нелогичным.

Не всё.

Когда я познакомился с Арчем после Дебиана, это был круто.

Аналогично когда я узнал про Докер.

Таких примеров можно много привести.

Ну, опять-таки, не без исключений, а исключения, как правило, подтверждают правило :) Невидиевский 390-й драйвер протух, но его по-прежнему патчат чуваки в AUR, а обновлять железку не хочется, тем более, что еë производительность меня пока устраивает. Да и привык я к ней, добротная. Рано или поздно это, конечно, придëтся сделать… А пока сижу с GeForce GT710M. И чувакам тем огромное спасибо. Я тоже без дела не сижу, и возможно, тоже скоро выкачу туда что-то на эту тему, если осилю.

Ну, если ты просто форматируешь /dev/root (или /boot, если он у тебя отдельный), то с чего бы флагу активного раздела сниматься…