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

И ещё камень в огород твоей «критической зоны». Полчаса наблюдаю обновление 330М (850М распакованные) пакетов на юсб-3 флешку с линейной скоростью более 100Мб/с и нелинейной 230-800Кб/с. Что то не вижу никакого превосходства - всё упёрлось в диск и никаких чудес не произошло. Ты точно уверен, что твоё «низкое время в критической зоне» не является быстрым дисковым кешем, а об отсутствии данных на диске ты узнаешь по сломаному пакету?

boot-флаг, внезапно, устанавливает/снимает не GRUB, а менеджер дисковых разделов

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

Ничего там сложного нет, конфиг почти такой же, как у grub-legacy.

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

Вы туда руками что-ли лезете? DO NOT EDIT THIS FILE

Именно! Это т файл не для людей. А мне надо открыть руками и прописать 1-2 строки. Так что граб0 имеет тотальное превосходство.

Странно, почему то раньше это делал именно установщик загрузчика

Покажи как и где, а то я в руководстве к grub-legacy этого не увидел.

Зачем - внятно объяснить не можешь

Ложь.

и как жить

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

если много логов на машине не нужно

Есть разница между «много логов не нужно» и «вообще логов не нужно».

Это буквально твои слова, кретин.

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

Из всех вариантов загрузчиков выбрать

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

Лучше всех был lilo :) Он и место почти не занимает, в отличие от того же grub-legacy ;)

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

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

Для больших дядей любой вылет - это потеря денег

Как я уже говорил выше, я не Гугл, не Амазон и даже не рядовой большой дядя. И очевидно для меня важнее не удалять гланды через жопу и чтобы логгер не дёргал лишний раз диск. И не существует никакой разумной причины чтобы команда из 3 слов превращалась в такой геморрой. В конце концов сделать rm -rf / я могу значительно легче а не рекомендуется это намного сильнее, а в продакшене так особенно. Тем не менее это не повод удалять rm или запрещать ему работать с корнем.

Я тебе напомню очевидную причину почему поттерингофанаты с таким остервенением сделали журналд неотключаемым: Их более 5-и лет массово посылали нахер с их поделием, преимущества журналда были неочевидны, работа не налажена а недостатки очевидны. Теперь у них комплексы, совршенно дефолтные для типичных NIX-революционеров.

это способ, предусмотренный проектировщики

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

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

Я пользуюсь им чуть меньше 20 лет и за это время мне всего пару раз приходилось ставить бут-флаг руками.

Дефолтный full install никогда нельзя считать рабочей системой. Кто то должен объяснить что именно пользователю нужно.

Напоминаю: мы замеряли время установки kde ( pacman -Ss kde | grep meta | grep -v kdevelop против kde-full

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

Если использовать дефолтное поведение dpkg с fsync - то тормоза еще более значительные.

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

И поэтому по настоящему критичеескими являются моменты изменения статуса юзермпейсных моментов в БД пакетов и файловые операции на дкритическими системными компонентами, но их пара сотен мегабайт из ~4-8Гб, т.е. не более 5%. Но из этих 5% также не всё время является критическим.

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

В моей башке существует простой вопрос: Это удобно? Это полезно? Мне это надо? Это лучше альтернативной версии? Что лучше, написать строчку в онфиге или написать строчку в другом конфиге и запустить конфигуратор, который переведёт один конфиг и на его основе запишет другой, при условии что конфиг 1-ого варианта ещё и удобней чем 2-ого варианта? А причины «дядя сказал что надо так» и тем более «левый чел сказал что надо так» при оценке множатся на угадай какой коэфицент важности.

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

И чем эти ограничения меня ограничивают? Ну вот лично ты будешь использовать GPT+LVM там где достоточно просто создать ФС прямо поверх блочного устройства? Или там, где тебе нужны 3 раздела?

Клован и дебьянопоклонник. Но.

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

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

Я уже и от GPT+protective MBR отказался, с переходом на GPT+EFI. LVM и прочее ZFS не использую, так как для домашнего компа это оверкилл, как по мне.

Работая на уровне монолитного образа системы ты по сути устанавливаешь её каждый раз заново. И это было бы полной жопой если бы не использовалась другая система, которая обрабатывает образ дочерней системы диффами и системой контроля версий, причём обязательно в то время, когда целевая система выключена. Хочешь внести в систему изменения на живую? В ней должен быть ПМ и пакеты, а образ должен быть немонолитным. Хочешь интегрировать софт в систему и совмещать его работу между собой? Нужно вносить изменения наживую.

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

прописать 1-2 строки.

$: cat /etc/grub.d/40_custom
#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.

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

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

?

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

Мне это не надо.

linux /boot/vmlunuz root=/dev/sda2 rw
initrd /boot/intel-ucode /boot/initramfs-linux.img

Это, если хочешь сам. Но уже давно можно просто править /etc/default/grub и не иметь проблем. Переустановка загрузчика после обновления ядра не требуется.

apt позволяет устанавливать и удалять пакеты по шаблону, типа такого: $ sudo apt install "tesseract*". Часто бывает нужно.
А для pacman есть похожее?

В том то и дело, что в моём дебиан-8 с отключенным журналдом - ни в чём ни при каких на протяжении последних 4 лет. Я надеюсь физические отключения питания или отвалы дисков мы не считаем за то, с чем мне мог бы помочь журналд?

На Пи4 и ноуте с дебианом - примерно аналогично, хотя кажется в пошлом году я где то зачем то запускал журналд и не помню помогли мне его логи или нет.

Хехе, вот тут меня аж заинтересовало. А ну ка проделай свой поиск не с aptitude, а с apt или вообще, с dpkg. Ведь сравнивать надо их, а не TUI.

pacman -S $(pacman -Ssq tesseract)

И как я тебе отмотаю время на 3-5 лет назад?

Ну, я же ссылку на руководство от grub-legacy сюда скидывал :)

Я даже не знал об этом ограничении потому что обе файлопомоки по 2Тб в моём распоряжении вообще не имеют таблицы разделов.

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

Чотаржу.

Но я всё ещё легко укладываюсь в 6-7 разделов при установки системы даже с А/В-корнем.

Ну, у pacman есть кэш пакетов, а еще есть Arch Linux Archive. Так что можно легко и просто откатиться на любое состояние системы.

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

Так в граб0 изначально так можно. Зачем менять шило на мыло?

ну дык просто пропиши туда что тебе надо, а не перелопачивай grub.cfg

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

pacman -Ssq …

Регэкспы/маски тоже можно?

pacman -S $(pacman -Ssq | grep -E ... )

Не думаю. В арче также есть высокоуровневые пакетники, но либо я чего то не заметил, либо там вообще нет TUI. Тем более такого простого, удобного и умного как аптитюд. Возможно голым apt-get было бы также неудобно пользоваться как и пакманом, но это совершенно не требуется. Так что извиняюсь, но во всём этом треде под дабиан/дпкг я почти всегда имел в виду debian-подобные + aptitude/dpkg в комадном или интерактивном режимах. Каждый раз всё это очень долго писать, а любой знакомый с деб-подобными и так знает.

Хотя бы потому, что он может в GPT только с защитным MBR и вообще не может в EFI. А с EFI вообще загрузчик не нужен, можно ядро напрямую грузить (UKI).

Что то не так? Ни разу не откатывли обновление потому что оно было всратым?

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

pacman -U /var/cache/pacman/pkg/<previous>

Вот именно. Для биос-совместимых систем удобнее граб0 если нет мультизагрузки на 2Тб+ диск в несколько ОС, а для ЭФИ вообще никакого граба не нужно.

Для биос-совместимых систем удобнее граб0

nope.

О, и ещё на малинах mbr+fat32 без вариантов, только без загрузчика на диске.

Ну, если разобраться, это проблема многого другого ПО, не только pacman’a. Но есть и длинные ключи и автодополнение.

Малинка тут сбоку припëка, если мы про декстопный арч vs debian спорим :)

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

Я бы в таком случае предпочëл бы lilo. Места не занимает, его не видно и не слышно (почти) :)

Не думаю
не заметил
Возможно

" Не знаю, но имею коспетентное мнение!!! "

Ты утёнок, как тут уже не раз говорили. Просто перестань нести околесицу, вылези из скорлупы и переосмысли и Дебьян и Арч. Посмотри на оба со стороны, а не через призму тонюсенькой дорожки протоптанной тобой в Дебьяне. Я не сомневаюсь, что ты понимаешь и умеешь в aptitude, но это не то, о чём гласят все документации для Дебьяна. Посиди с ключиками dpkgпогрепай и полессай. Умник...

И у меня есть секретная ссылка на документацию Арча, где рассказывают о tui пакетных менеджерах. Да что там, даже о gui!!! Мне её в гугле дали и я обещял никому ни за что её не давать. Сходи тоже в гугл. Но если спросят откуда ты узнал, не упоминай меня.