Советы по GNU/Linux – Telegram
Советы по GNU/Linux
155 subscribers
203 photos
6 videos
43 files
314 links
Канал, посвящённый GNU/Linux и свободному ПО.

Другие наши каналы:

@calmira_gnu_linux - чат по дистрибутиву Calmira GNU/Linux-libre, который разрабатывает один из админов этого канала
Download Telegram
Человек давно присматривается к AppImage. Думаю, его идея неплоха.

Писать сюда: @spyjeru
3
Forwarded from spider jerusalem
я собираюсь делать сайт для AppImage и мне нужна ваша помощь
кто мне нужен?

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

напишите в личку с пометкой #linuxappstore (с октокорпом), покажу что есть, что нужно доработать и т.д.
6🎅1
Пару мыслей о структуре директорий в современных 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, отношение его разработчиков к ошибкам и странностям поистине странное.

#МыслиВслух
👍51
Пришло время нескучных опросов. Какое вы предпочитаете рабочее окружение?
Anonymous Poll
44%
GNOME
56%
KDE
21%
Xfce
5%
MATE
14%
Cinnamon
3%
LXDE
5%
LXQt
2%
Pantheon
6%
Unity
PID какого-то процесса равен единице. Что это за процесс?
Anonymous Quiz
34%
/usr/bin/init
50%
/sbin/init
6%
/bin/gdm
10%
/usr/bin/pulseaudio
На протяжении долгого времени использовал текстовый редактор Vim. Это и написание каких-либо статей, и редактирование конфигов, и кодинг. Короче - Vim был эдакой рабочей лошадкой. Летом 2022 года пересел на neovim - посоветовали как-то, решил попробовать и втянулся в это всё дело. Ну а сейчас в команде разработчиков @calmira_gnu_linux посоветовали текстовый редактор Helix. Его разрабы явно были вдохновлены Vim/Neovim, и, например, какие-то команды и сочетания клавиш там похожи. Не всё, конечно, но мне было очень легко перейти.

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

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

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

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

Поэтому если кто-то хочет попробовать что-то новое, то могу посоветовать именно этот текстовый редактор.
👍8
👍3
Сегодня дистрибутиву Arch Linux исполняется 21 год 🥰🥳. Первая версия этого дистрибутива (0.1) вышла 12 марта 2002 года. Использовала ядро Linux 2.4.18.
10👍4
Делаем правильные мемы о наложении патча Бармина.

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

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

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

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

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

#include <iostream>

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
👍5🥰3
Тащемта уже в эту субботу должен состояться релиз tar-архивов GNOME 44.0
👍8🔥3👏1🤮1
Сегодня исполняется 70 лет Ричарду Столлману — основателю Фонда свободного ПО, проекта GNU и Лиги за свободу программирования. Внёс большой вклад как в развитие современных свободных ОС (GNU/Linux как пример), так и в развитие свободного ПО в целом. Одной из его заслуг является также создание свободной лицензии GNU GPL, предоставляющую пользователям свободу копировать, модифицировать и распространять (в том числе на коммерческой основе) ПО.
Мы поздравляем его с юбилеем. Желаем сил и возможностей и для дальнейшей работы в GNU и FSF. За свободным ПО будущее!
🎉76👍2
Тащемта основной софт уже обновился до 44 версии. GNOME Shell 44 выйдет 22 марта
👍93
#Humor

———————————————

На основном ноуте стоит такая 15,6" матрица. Не матрица, а говно. Хотя в качестве печатной машинки использовать вполне возможно — а что ещё надо? Сам ноут 2013 года выпуска, поэтому ему простительно.
👍1
Channel photo updated
👍41🤡1
Ну всё. Обе петли в ноуте приказали долго жить
😢5
С другой стороны, не каждый ноут может похвастаться углом раскрытия в 180 градусов, ни тогда, ни сейчас. Считай, ультрабук теперь
😁3
https://github.com/nate-xyz/resonance

Вот такой вот моднявый музыкальный плеер для GNOME. Что-то среднее между GNOME Music и Amberol.
🔥3