И кто мешает при удалении указать префикс dd, чтобы не ломало зависимости
-Rdd то как раз и ломает зависимости позволяя удалить указанный пакет несмотря на то что от него напрямую зависят другие пакеты тем самым "ломая" их работу, поэтому я постом ниже и написал что при таком удалении
ты либо ССЗБ либо действительно осознаёшь для чего ты это делаешь.
в Арче в 99,99% случаях для безболезненного удаления пакета всегда вполне хватает и простого -R ; если же ругается на зависимости то либо их также удалить(перечислив по одному или же все скопом с помощью ключа -c, --cascade) либо и вовсе ничего не трогать.
нет, вы ошибаетесь, следить а тем более "держать в голове зависимости" не нужно, здесь всё так же как и в стандартных linux дистрибутивах, точнее в пакетных менеджерах; pacman(ПМ Арча) за этим следит, и если нужно заблокирует деструктивное действие выдав соответствующую информацию, например, недавно обновил систему, один из пакетов при обновлении luajit, попробуем его удалить:
$ sudo pacman -R luajit
проверка зависимостей...
ошибка: не удалось подготовить транзакцию (не удалось удовлетворить зависимости)
:: removing luajit breaks dependency 'luajit' required by gamescope
:: removing luajit breaks dependency 'luajit' required by gegl
:: removing luajit breaks dependency 'luajit' required by libluv
:: removing luajit breaks dependency 'luajit' required by mpv
:: removing luajit breaks dependency 'luajit' required by xplr
то есть чтобы его удалить тебе нужно удалить все перечисленные пакеты которые зависят от данного пакета. Можно конечно упороться и сделать это в лоб
sudo pacman -Rdd luajit
но тут два варианта, ты либо ССЗБ либо действительно осознаёшь для чего ты это делаешь.
При установке конфликтующих пакетов похожая история, при обнаружении конфликта вам предложат либо прервать установку либо заменить на устанавливаемый пакет.
Если говорить в общем относительно основного поста, то вполне сойдут и несколько цитат из арчвики:
Arch нацелен на опытных пользователей, которым нравится его подход "сделай сам", и которые могут настроить систему для удовлетворения своих собственных нужд.
Если вы новичок и желаете использовать Arch, имейте в виду, что вам придется набраться терпения и потратить значительное время на постройку и освоение новой системы, а также принять тот факт, что в основе Arch лежит принцип "сделай сам" ("Do It Yourself"). Именно пользователь собирает систему из компонентов и определяет то, какой она должна быть.
если вам это не по нраву то это нормально, люди разные как и их потребности.
– Нет-нет! Не думаю, что нам это понадобится! – поспешно прервал его Грид. – Меня интересуют только общеизвестное. Я бы хотел обобщить некоторые моменты истории, предпосылки постоянных конфликтов между истцом и ответчиком, которые могли сильно замедлить или даже поставить под угрозу сам проект. Вот, к примеру, расскажите суду о проблемах «биохимической стандартизации» в меловом периоде. Ведь тогда стараниями истца едва не уничтожили плоды сотни миллионов лет направленной эволюции!
– Я протестую, ваша Высокобожественность! – вскочил Снорк. – В вопросе к свидетелю содержится вывод! Да если бы не…
– Протест принят! – вяло махнул ластой Норр. – Свидетель, прошу воздержаться от оценочных суждений. Только факты.
– Как скажете… – кивнул Чуки, отчего верхняя часть облачка комично свесилась вперед, словно съехав по невидимым рельсам. – Как известно, все крупные биологические молекулы могут находиться в двух пространственных конфигурациях с поворотом плоскости поляризации света влево или вправо. Изначально зоо-дизайнеры сделали аминокислоты с левым винтом, а двойную спираль ДНК с правым.
– Эти подробности действительно важны для процесса? – недовольно осведомился морж-глашатай, видимо транслируя удивление «безымянного».
– Я только отвечаю на поставленный вопрос, ваша Высокобожественность! – нахмурился Чуки, сверкнув над амбразурами глаз мелкими молниями. – В этот период динозавры Мары еще доминировали на планете, не давая возможности развития альтернативных проектов. Тогда Нима изменила поляризацию молекул тела перспективных млекопитающих на противоположную!
– И что? – недоуменно спросил Норр.
– Прежние организмы не смогли их усваивать! Они испытывали ложное насыщение, набивая желудки едой, которая не давала им ни капли энергии. Законы химии действуют одинаково как в «левом», так и в «правом» мире. Млекопитающие Нимы и их кормовая база теперь состояли из зеркально симметричных молекул, образовав «теневую биосферу». Ее члены не конкурировали со старыми формами жизни и не обменивались с ними генами. Фокус был в том, что ящеры стали сытыми дохнуть от голода, освобождая место для маленьких пушистых бестий. Какое изящное решение, не правда ли? – захихикал архивариус.
– Я бы не сказал так о проблеме, поставившей под угрозу результат работы всего коллектива! – возмущенно прошипел Грид. – Это нечестный и подлый прием!
– В служебных правилах нет прямого запрета на здоровую конкуренцию! – возразил Снорк. – К тому же, Ниму в этот период вывели за штат из-за интриг Мары. И мы все знаем, чем это закончилось! Если бы не она, то ваши зубастые чудища до сих пор бы жрали друг друга в джунглях! Проект давно бы лишили финансирования!
– Неизвестно, что было… – начал контратаку Грид, но его прервал громкий шлепок ластами.
– У Мары эта проблема отняла уйму времени, но он все же нашел решение! – с ехидцей произнес Чуки. – Он подселил к ящерам микроорганизм-конвертер, который химически изменял аминокислоты и сахар, переводя их в нормальную форму. Таким образом, «гонка вооружений» закончилась ничем, но на нее потратили немало ресурсов и времени. У меня сохранились ведомости, где…
– Достаточно! – прервал его глашатай. – У представителя истца есть вопросы к свидетелю?
думаю тут главный вопрос в другом - всё это должно будет как-то отслеживаться и где-то учитываться, а в перспективе наверное даже как-то ограничиваться.
с чего бы ? он скорее всего даже на 8-гиговой машине установиться без проблем
загружаемый пакет весит порядка 3гиг, а точнее
$ sudo pacman -S cuda
разрешение зависимостей...
проверка конфликтов...
Пакет (4) Новая версия Изменение размера Размер загрузки
extra/gcc14 14.3.1+r25+g42e99e057bd7-1 172,66 MiB 43,40 MiB
extra/gcc14-libs 14.3.1+r25+g42e99e057bd7-1 0,87 MiB 0,30 MiB
extra/opencl-nvidia 580.76.05-4 85,55 MiB 5,65 MiB
extra/cuda 12.9.1-2 7191,42 MiB 2788,18 MiB
Будет загружено: 2837,52 MiB
Будет установлено: 7450,51 MiB
:: Приступить к установке? [Y/n]
даже если предположить что размер /tmp оставлен по дефолту а это 50% от ОЗУ, то для 8-гиговой в запасе еще останется чуть больше 1 гига для загрузки остальных пакетов и той "мишуры" что обычно по дефолту лежит в /tmp (понятное дело что для пользования 8-гиговой машинкой нужен определённый аскетизм в плане DE, браузера со 100500 запущенных вкладок и других программ одновременно нагружающими машину, конечно можно использовать своп и другие приблуды по типу zram, но тут уже кто как может так и ...) На саму распаковку(~7.5 гиг) tar/zst тратить довольно мало памяти, порядка 40 мб если судить по htop, упор в основном идёт на использование процессора. Ну а чтобы не оставлять эти несколько гиг лежать мёртвым грузом до перезагрузки то можно воспользоваться хуком из моего комментария выше, тогда после установки пакетов ОЗУ станет девственно чистой как и до их установки.
p.s. для более эффективного задействования ОЗУ через /tmp, ведь туда можно скидывать не только кэши пакмана но и много чего еще для увеличения быстродействия и сохранения ресурса диска, можно задать в /etc/fstab размер \tmp в 70,80 или даже 90%
если событие(установка, обновление) у нас привязано к пакману то логично будет использовать его хук а не какой-то отвлечённый таймер. вот когда-то использовал что-то типа такого:
где k1(здесь за комментирован) оставить только последнее поколение пакетов в кэше; k0 зачистить кэш полностью и всё это проделать после(PostTransaction) события установки/обновления/удаления пакетов
если у вас установлена система с ролинг-релизом по типу arch-а которая подразумевает частые обновления в том числе критически важных систем вроде ядра и разных драйверов, то редкие перезагрузки системы при частом обновлении это очень плохая идея. Те же ядра обычно выпекают 1-2 раза в неделю https://gitlab.archlinux.org/archlinux/packaging/packages/linux/-/commits/main, перезагрузка после установки оных крайне рекомендуется делать, чтобы потом не гадать а что же пошло не так.
в общем, очистка происходит естественным образом при перезагрузке компьютера.
раньше использовал хук для пакмана который оставлял к кэше только последнее поколение пакетов вместо стандартных трёх, но сегодня считаю даже это расточительным с учетом доступности интернета и такого ресурса как https://archive.archlinux.org
да я не противоставляю fdisk и sfdisk, это по сути одно "кодло" но разной заточености на интерфейс взаимодействия с пользователем )) там акцент делался на левый gdisk
а примеры, то я так, просто для разминки привёл )
кстати, по поводу наглядности у sfdisk, тут ведь как ...
-Rdd то как раз и ломает зависимости позволяя удалить указанный пакет несмотря на то что от него напрямую зависят другие пакеты тем самым "ломая" их работу, поэтому я постом ниже и написал что при таком удалении
в Арче в 99,99% случаях для безболезненного удаления пакета всегда вполне хватает и простого -R ; если же ругается на зависимости то либо их также удалить(перечислив по одному или же все скопом с помощью ключа -c, --cascade) либо и вовсе ничего не трогать.
нет, вы ошибаетесь, следить а тем более "держать в голове зависимости" не нужно, здесь всё так же как и в стандартных linux дистрибутивах, точнее в пакетных менеджерах; pacman(ПМ Арча) за этим следит, и если нужно заблокирует деструктивное действие выдав соответствующую информацию, например, недавно обновил систему, один из пакетов при обновлении luajit, попробуем его удалить:
то есть чтобы его удалить тебе нужно удалить все перечисленные пакеты которые зависят от данного пакета. Можно конечно упороться и сделать это в лоб
но тут два варианта, ты либо ССЗБ либо действительно осознаёшь для чего ты это делаешь.
При установке конфликтующих пакетов похожая история, при обнаружении конфликта вам предложат либо прервать установку либо заменить на устанавливаемый пакет.
Если говорить в общем относительно основного поста, то вполне сойдут и несколько цитат из арчвики:
если вам это не по нраву то это нормально, люди разные как и их потребности.
a поподробнее можно ?
Евгений Кострица / Сансара / Лабиринты разума
а мне нравиться использовать его(bash) как клей для стандартных unix/linux утилит
взгляд сразу цепляется за "блоки" и легко воспринимать
если кому интересны первоисточники
https://www.city.toyoake.lg.jp/item/31472.htm
https://www.city.toyoake.lg.jp/item/31475.htm
думаю тут главный вопрос в другом - всё это должно будет как-то отслеживаться и где-то учитываться, а в перспективе наверное даже как-то ограничиваться.
с чего бы ?
он скорее всего даже на 8-гиговой машине установиться без проблем
загружаемый пакет весит порядка 3гиг, а точнее
даже если предположить что размер
/tmpоставлен по дефолту а это 50% от ОЗУ, то для 8-гиговой в запасе еще останется чуть больше 1 гига для загрузки остальных пакетов и той "мишуры" что обычно по дефолту лежит в/tmp(понятное дело что для пользования 8-гиговой машинкой нужен определённый аскетизм в плане DE, браузера со 100500 запущенных вкладок и других программ одновременно нагружающими машину, конечно можно использовать своп и другие приблуды по типу zram, но тут уже кто как может так и ...)
На саму распаковку(~7.5 гиг)
tar/zstтратить довольно мало памяти, порядка 40 мб если судить поhtop, упор в основном идёт на использование процессора.Ну а чтобы не оставлять эти несколько гиг лежать мёртвым грузом до перезагрузки то можно воспользоваться хуком из моего комментария выше, тогда после установки пакетов ОЗУ станет девственно чистой как и до их установки.
p.s.
для более эффективного задействования ОЗУ через
/tmp, ведь туда можно скидывать не только кэши пакмана но и много чего еще для увеличения быстродействия и сохранения ресурса диска, можно задать в/etc/fstabразмер\tmpв 70,80 или даже 90%если событие(установка, обновление) у нас привязано к пакману то логично будет использовать его хук а не какой-то отвлечённый таймер.
вот когда-то использовал что-то типа такого:
где
k1(здесь за комментирован) оставить только последнее поколение пакетов в кэше;k0зачистить кэш полностьюи всё это проделать после(PostTransaction) события установки/обновления/удаления пакетов
если у вас установлена система с ролинг-релизом по типу arch-а которая подразумевает частые обновления в том числе критически важных систем вроде ядра и разных драйверов, то редкие перезагрузки системы при частом обновлении это очень плохая идея. Те же ядра обычно выпекают 1-2 раза в неделю https://gitlab.archlinux.org/archlinux/packaging/packages/linux/-/commits/main, перезагрузка после установки оных крайне рекомендуется делать, чтобы потом не гадать а что же пошло не так.
это конечно хорошо, но как по мне лучше искоренить проблему на корню.
Зачем постоянно чистить кэш если можно его просто разместить в оперативке
а за одно и сборочный полигон от aur-хелпера, пример для yay:
в общем, очистка происходит естественным образом при перезагрузке компьютера.
раньше использовал хук для пакмана который оставлял к кэше только последнее поколение пакетов вместо стандартных трёх, но сегодня считаю даже это расточительным с учетом доступности интернета и такого ресурса как https://archive.archlinux.org
для пользователя наверное всё же проще будет использовать ту же утилиту
udisksctlкоторая входит в состав udisksназвание GuixSD использовалось до релиза 1.0 (в 2019 году), после уже просто Guix (System)
Почему выражение “свободные программы” лучше, чем “открытый исходный текст”
теперь встаёт вопрос - сколько нужно баб чтобы за день родить 10 детей ?)
человеки наверное мешают, тот же апгрейд оборудования, наладка, тестирование ...
да я не противоставляю fdisk и sfdisk, это по сути одно "кодло" но разной заточености на интерфейс взаимодействия с пользователем )) там акцент делался на левый gdisk
а примеры, то я так, просто для разминки привёл )
кстати, по поводу наглядности у sfdisk, тут ведь как ...
под таким углом выглядит уже довольно наглядно )
эх, и вот так лёгким мановением руки подменили третьего богатыря ))
у нас по сути есть два подобных набора инструментов для работы с разделами:
fdisk, cfdisk, sfdisk
gdisk, cgdisk, sgdisk
где отличием в группе является лишь интерфейс взаимодействия - интерактив, псевдографика или командно-скриптовой
в общем, если кто не догадался то по логике вещей вместо gdisk стоило бы указать sfdisk.
и если, для примера, заменить интерактив fdisk через sfdisk для UEFI то получим:
ну или чуть покороче:
аналогично для BIOS:
короткий вариант:
более подробно про это можно прочитать в арчвики - GUID_Partition_Table_(GPT)_specific_instructions
хотя помниться в своё время для BIOS/(MBR|GPT) использовал syslinux и там вроде как удавалось обходиться без отдельного раздела
что касается UEFI/GPT то как по мне вполне достаточно и встроенного systemd-boot
ага, недавно исполнилось 170 лет шагающей партии США (дем. и рес. как две ноги шагая сменяют друг друга)