Советы по GNU/Linux

2023-03-13 21:51:00 Тащемта уже в эту субботу должен состояться релиз GNOME 44.0 Открыть/Комментировать

2023-03-13 16:05:20 Делаем правильные мемы о наложении патча Бармина.

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

Часто советуют команду rm -rf или rm -rf /. Первая команда явно неправильна - ей не переданы аргументы кроме ключей -rf, которые предназначены для удаления директорий. А имя самОй директории-то не предоставлено - что тогда нужно удалить?

А со второй командой куда интереснее. Многие говорят, что без "волшебного ключика" --no-preserve-root ничего не будет работать. А вот нет. Поэтому думаю, что стоит описать поведение символа * в UNIX Shell.

См. вывод echo * в BASH или другой оболочке.

Простейшая программа на C++ покажет вам:

#include

int main(int argc, char** argv) {
for(int i=1; i <= argc, i++) {
std::cout << argv[i] << std::endl;
}
}

Использование:

./program *

Вывод в консоль:

.ICEauthority
.Xauthority
.android
.bash_history
.bash_logout
.bash_profile
.bashrc
.cache
.cargo
Видео
Документы
Загрузки
Изображения
Музыка
...

Т.е. будет выведено содержимое текущей рабочей директории. Если мы изменим команду до следующей:

./program /*

То вывод будет следующим:

/bin
/boot
/dev
/etc
/home
...

Это связано с тем, что оболочка (shell) вместо символа * программе передаёт список всех файлов либо текущей рабочей директории, либо указанной.

Программа rm (по крайней мере из состава GNU Coreutils) не будет удалять файлы в корне, если в качестве аргумента передать путь /. А если мы передадим аргумент /*, то оболочка заменит его на список всех найденных в корне файлов и rm это с удовольствием скушает. Если rm запущена от имени обычного пользователя, то ничего страшного не произойдёт - системные файлы удалены не будут, поскольку у rm в данном случае к ним нет доступа, но будут удалены файлы пользователя. Ну а если вы запустили rm -rf /* от имени пользователя root, то тут могу принести вам соболезнования.

Следовательно, для удаления файлов системы мы можем указывать следующие команды:

1. rm -rf / --no-preserve-root
2. rm -rf /*

Какой вариант использовать - решайте сами. Но ответственность за все ваши файлы несёте вы сами :)

#Tips #Bash

99 viewsМихаил, edited  13:05

Открыть/Комментировать

2023-03-12 00:02:26 Сегодня дистрибутиву Arch Linux исполняется 21 год . Первая версия этого дистрибутива (0.1) вышла 12 марта 2002 года. Использовала ядро Linux 2.4.18. Открыть/Комментировать

2023-03-11 00:33:49 Открыть/Комментировать

2023-03-11 00:33:46 На протяжении долгого времени использовал текстовый редактор Vim. Это и написание каких-либо статей, и редактирование конфигов, и кодинг. Короче - Vim был эдакой рабочей лошадкой. Летом 2022 года пересел на neovim - посоветовали как-то, решил попробовать и втянулся в это всё дело. Ну а сейчас в команде разработчиков @calmira_gnu_linux посоветовали текстовый редактор Helix. Его разрабы явно были вдохновлены Vim/Neovim, и, например, какие-то команды и сочетания клавиш там похожи. Не всё, конечно, но мне было очень легко перейти.

Из достоинств Helix можно сразу отметить его настройку. Никаких скриптов и прочих языков программирования. Вся настройка производится в нескольких toml-конфигах. Это просто, быстро и удобно. Конечно, кастомайз в таком случае не такой уж и широкий, как в (neo)vim, но мне вполне достаточно того, что есть.

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

Ну и всякие прочие плюшки вроде красивых тем оформления, более продвинутой по сравнению с Vim подсветкой синтаксиса и даже какой-никакой интеграцией с git. По крайней мере выделяет изменённые/удалённые/добавленные строки, как это делают всякие разные IDE.

Редактор написан на Rust. В принципе, на этом языке пытаются написать, кажется, всё, что попадётся под руку. И это неплохо — Rust является неплохой альтернативой С/С++.

Поэтому если кто-то хочет попробовать что-то новое, то могу посоветовать именно этот текстовый редактор. Открыть/Комментировать

2023-03-01 12:29:55 Опубликованы Linux From Scratch 11.3 и Beyond Linux From Scratch 11.3 https://opennet.ru/58727/ Открыть/Комментировать

2023-02-18 17:59:15 Открыть/Комментировать

2023-02-18 17:58:52 Пару мыслей о структуре директорий в современных GNU/Linux

У нас есть стандарт FHS (Filesystem Hierarchy Standard), который унифицирует расположение необходимых файлов в нужных директориях, используется во всяких разных UNIX-системах, в т.ч. и во многих дистрибутивах GNU/Linux. Ну и директории там тоже описаны.

Согласно этому стандарту, помимо всех остальных каталогов, у нас есть каталоги /bin, /sbin (для хранения двоичных бинарных файлов программ) и /lib для хранения файлов библиотек. В этих директориях, в общем, содержатся файлы, необходимые для работы системы. По крайней мере, обеспечивающие ей хотя бы загрузку. Есть каталог /usr, который также содержит /bin, /sbin и /lib, эти подкаталоги также содержат файлы программ и библиотек, но, как правило, тех программ, которые системными не являются. Эти программы, как правило, устанавливаются либо пользователем, либо сборщиком дистрибутива GNU/Linux.

Вообще в FHS прописано, что файлы в каталогах /{bin,sbin,lib} предназначены для всех ситуаций, в том числе и тех, когда система загружена в однопользовательском режиме, а в /usr/{bin,sbin,lib} - для той ситуации, когда система загружена в обычном режиме.

Но современные дистрибутивы GNU/Linux почему-то убирают эти самые /{bin,sbin,lib}, заменяя их ссылками на соответствующие каталоги в /usr. В результате, в /usr/bin, /usr/sbin, /usr/lib у нас содержатся вообще все программы: и те, которые предназначены для многопользовательского режима, и те, которые предназначены и для того, и для однопользовательского режима системы.

Когда я собирал LFS (в которой также всё заменили на ссылки) я затёр /bin. Это произошло по чистой случайности, когда я тестировал написанный буквально на коленке пакетный менеджер (а точнее - просто прогу для установки и удаления ПО, не более). В результате пришлось пересобирать систему, ибо считай достаточно важную часть я просто удалил. В случае раздельной структуры каталогов (будем называть её так) мне было бы проще её восстановить.

Однако у такой "современной" структуры каталогов есть плюс - собирать ПО несколько проще. Ибо собранное из исходного кода ПО, даже если оно системное, почему-то устанавливается в /usr/*, что не является правильным, поэтому приходится иногда перемещать кучу файлов в ту или иную директорию в /. В случае такой вот современной совмещённой структуры этих действий выполнять не требуется. Однако нужно использовать систему (и экспериментировать с ней) чуть осторожнее.

Второй причиной использования такой структуры является... systemd! По заявлению кого-то из разработчиков этот инит не совсем корректно в некоторых случаях работает в системах, где /{bin,lib,sbin} - отдельные каталоги, а не ссылки. Поэтому в скором времени от раздельной структуры каталогов в systemd планируют отказаться. Одно время при сборке он даже выводил сообщение об этом. Знаете, несмотря на все плюсы systemd, отношение его разработчиков к ошибкам и странностям поистине странное.

#МыслиВслух Открыть/Комментировать

2023-02-12 01:37:55 я собираюсь делать сайт для AppImage и мне нужна ваша помощь
кто мне нужен?

frontend: html+css+js
дизайнеры: figma, lunacy
спецы по деплоингу: будем хостить без бэкенда на github pages через статический генератор сайтов

напишите в личку с пометкой #linuxappstore (с октокорпом), покажу что есть, что нужно доработать и т.д. Открыть/Комментировать

2023-02-12 01:37:55 Человек давно присматривается к AppImage. Думаю, его идея неплоха. Открыть/Комментировать