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

1. Подключение плагина:

Plug 'akinsho/toggleterm.nvim', {'tag' : '*'}

2. Собственно, использование. Я забиндил т.н. "плавающий" (см. скрин выше) на сочетание ,tt:

lua << EOF
require('toggleterm').setup{}
EOF
nnoremap ,tt :Toggleterm size=40 direction=float

https://www.linux.org.ru/news/kde/17015534

Как же я мог пропустить?

Тем временем завершился рефакторинг cport. По причине моей занятости и отсутствия желания что-либо делать он затянулся на несколько месяцев, ибо коммитил не так часто, как хотелось.

Из планов на будущее:

- Возобновить работу над пакетным менеджером cpkg.
- Интеграция с AppImage Installer.

Всех с новым годом! 2022 год, как и все предыдущие, полное говно. Но, в отличие от предыдущих, говно особое, при чём не просто для каких-то отдельных людей, а для многих. Поэтому очень надеюсь, что и 2023 год будет говном, но не таким ядрёным, а чуть попроще и полегче.

Желаю всем любви, мира, тишины и спокойствия. И чтобы самые сокровенные желания сбывались 😉.

Человек из команды разработчиков Calmira GNU/Linux-libre пилит установщик этой системы. Понаблюдать за прогрессом можно в репозитории: https://gitlab.com/calmiralinux/calminstall

Ну что, спустя 666 лет реализовали вот такой режим просмотра в диалоге выбора файлов - в виде иконок! Этого не было ни в GTK 1, ни в GTK 2 или 3. Инновации, хуле!

https://habr.com/ru/post/716306/

Использование сторонних компонентов от других разработчиков в своих программах сильно упрощает жизнь и ускоряет процесс разработки. Однако есть вот такой минус :)

У записи выше пропали коменты. Печаль(

Человек давно присматривается к AppImage. Думаю, его идея неплоха.

Писать сюда: @spyjeru

я собираюсь делать сайт для AppImage и мне нужна ваша помощь
кто мне нужен?

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

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

Пару мыслей о структуре директорий в современных 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, отношение его разработчиков к ошибкам и странностям поистине странное.

#МыслиВслух

Опубликованы Linux From Scratch 11.3 и Beyond Linux From Scratch 11.3 https://opennet.ru/58727/

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

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

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

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

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

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

Сегодня дистрибутиву Arch Linux исполняется 21 год 🥰🥳. Первая версия этого дистрибутива (0.1) вышла 12 марта 2002 года. Использовала ядро Linux 2.4.18.