– Нет-нет! Не думаю, что нам это понадобится! – поспешно прервал его Грид. – Меня интересуют только общеизвестное. Я бы хотел обобщить некоторые моменты истории, предпосылки постоянных конфликтов между истцом и ответчиком, которые могли сильно замедлить или даже поставить под угрозу сам проект. Вот, к примеру, расскажите суду о проблемах «биохимической стандартизации» в меловом периоде. Ведь тогда стараниями истца едва не уничтожили плоды сотни миллионов лет направленной эволюции!
– Я протестую, ваша Высокобожественность! – вскочил Снорк. – В вопросе к свидетелю содержится вывод! Да если бы не…
– Протест принят! – вяло махнул ластой Норр. – Свидетель, прошу воздержаться от оценочных суждений. Только факты.
– Как скажете… – кивнул Чуки, отчего верхняя часть облачка комично свесилась вперед, словно съехав по невидимым рельсам. – Как известно, все крупные биологические молекулы могут находиться в двух пространственных конфигурациях с поворотом плоскости поляризации света влево или вправо. Изначально зоо-дизайнеры сделали аминокислоты с левым винтом, а двойную спираль ДНК с правым.
– Эти подробности действительно важны для процесса? – недовольно осведомился морж-глашатай, видимо транслируя удивление «безымянного».
– Я только отвечаю на поставленный вопрос, ваша Высокобожественность! – нахмурился Чуки, сверкнув над амбразурами глаз мелкими молниями. – В этот период динозавры Мары еще доминировали на планете, не давая возможности развития альтернативных проектов. Тогда Нима изменила поляризацию молекул тела перспективных млекопитающих на противоположную!
– И что? – недоуменно спросил Норр.
– Прежние организмы не смогли их усваивать! Они испытывали ложное насыщение, набивая желудки едой, которая не давала им ни капли энергии. Законы химии действуют одинаково как в «левом», так и в «правом» мире. Млекопитающие Нимы и их кормовая база теперь состояли из зеркально симметричных молекул, образовав «теневую биосферу». Ее члены не конкурировали со старыми формами жизни и не обменивались с ними генами. Фокус был в том, что ящеры стали сытыми дохнуть от голода, освобождая место для маленьких пушистых бестий. Какое изящное решение, не правда ли? – захихикал архивариус.
– Я бы не сказал так о проблеме, поставившей под угрозу результат работы всего коллектива! – возмущенно прошипел Грид. – Это нечестный и подлый прием!
– В служебных правилах нет прямого запрета на здоровую конкуренцию! – возразил Снорк. – К тому же, Ниму в этот период вывели за штат из-за интриг Мары. И мы все знаем, чем это закончилось! Если бы не она, то ваши зубастые чудища до сих пор бы жрали друг друга в джунглях! Проект давно бы лишили финансирования!
– Неизвестно, что было… – начал контратаку Грид, но его прервал громкий шлепок ластами.
– У Мары эта проблема отняла уйму времени, но он все же нашел решение! – с ехидцей произнес Чуки. – Он подселил к ящерам микроорганизм-конвертер, который химически изменял аминокислоты и сахар, переводя их в нормальную форму. Таким образом, «гонка вооружений» закончилась ничем, но на нее потратили немало ресурсов и времени. У меня сохранились ведомости, где…
– Достаточно! – прервал его глашатай. – У представителя истца есть вопросы к свидетелю?
думаю тут главный вопрос в другом - всё это должно будет как-то отслеживаться и где-то учитываться, а в перспективе наверное даже как-то ограничиваться.
с чего бы ? он скорее всего даже на 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, тут ведь как ...
В Арче очень не хватает отдельного репозитория games.
тоже как-то думал об этом, но как по мне лучше если бы разделение реп сделали по графике, то есть, все что обязательно требует для своей работы какой-либо графический тулкит выделить в отдельную репу
Евгений Кострица / Сансара / Лабиринты разума
а мне нравиться использовать его(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 лет шагающей партии США (дем. и рес. как две ноги шагая сменяют друг друга)
тоже как-то думал об этом, но как по мне лучше если бы разделение реп сделали по графике, то есть, все что обязательно требует для своей работы какой-либо графический тулкит выделить в отдельную репу
немного вспомнилось о докладе - "Simple Made Easy" - Rich Hickey (2011)
ну, я бы не сказал что установка минимальна, основная система "средней наполненности" с двумя DE(gnome и sway)
хоть явно установленных пакетов не так много
но если брать с зависимостями то будет уже поболее
для сравнения домашний мини-сервер на арч арм