.ssh/unknown_hosts

Когда ssh подключается к неизвестному хосту она зачем-то просит человека написать "yes". Никто не знает зачем это нужно делать, но без этого ssh не подключается.

Но этого можно избежать этими двумя способами:

# 1. Отключить опцией (небезопасно)
$ ssh -o "StrictHostKeyChecking no" user@example.com
# 2. Автоматически сделать так чтобы хост был известным
$ ssh-keyscan -t rsa example.com >> ~/.ssh/known_hosts
$ ssh user@example.com

Во втором случае не будет предупреждения! Но не потому что мы просто отключаем проверку, а мы делаем хост нам известным!

Теперь вы понимаете что профессионала отличает то какие способы он выбирает! Будьте профессионалами, выбирайте безопасность!

#linux #ssh #safety

english version

2025.11.22 23:39

apache@docker

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

То есть как бы апач, а как бы и внутри докера.

То есть вот вас вроде бы и тошнит, а вроде бы и в пакет.

#linux #apache

2025.11.12 21:24

Шорткаты терминала

В терминале можно неплохо удалять. Например, если у вас есть строка и курсор в центре:

xxx xxx █ xxx xxx

То вы можете:
CTRL+W чтобы удалить слово слева
ALT+D чтобы удалить слово справа

Почему?

#linux #why #wtf

2025.11.10 23:17

Деплой статического блога через ssh и git --bare

Эпиграф

Когда у меня будет депрессивная фаза я никому не скажу, но будут признаки.

Начало

Вы уже прочитали первый пост и второй пост про как и зачем мы git --bare и всё ещё не понимаете зачем.

Давайте представим что у нас есть статический сайт и мы хотим его деплоить с локального устройство на серверное устройство. Мы всё тоже самое можем сделать через гитхаб, но мы можем и без!

Я вам расскажу как без, но это вряд ли оптимальный способ жить:
+ весело
+ независимо
– если у вас много картинок, то блог будет занимать x2 или даже сильно хуже
– гитхаб даст третью точку для бекапа

Но нам нужно весело поэтому давайте веселиться! Но вы можете всё тоже самое сделать и через гитхаб, просто не тоже самое!

Подготавливаемся

1. делаем ssh

Допустим у нас есть блог hshhhhh.name, на сервере пользователь тоже hshhhhh.name и мы уже можем подключиться к нему по ssh.

Теперь мы добавим в ~/ssh/config:

Host hshhhhh.name
    HostName 159.223.250.0
    IdentityFile ~/.ssh/keys/hshhhhh.name
    User hshhhhh.name

Теперь работает так:

$ ssh hshhhhh.name

2. подготавливаем сервер

Мы будем направлять nginx на директорию /home/hshhhhh.name/public_html/ потому что мы чтим традиции и уважаем чтение традиций. Поэтому мы создадим на сервере один git --bare и один нормальный, нормальный будет получать апдейты из git --bare, а потом нгинкс через симлинк будет ходить в нормальный.

Или на локальном устройстве, или на удалённом устройстве:

$ ssh hshhhhh.name "git init --bare ~/.git--bare"
$ ssh hshhhhh.name "mkdir ~/git/"

3. делаем блог

Внутри нашего репозитория тоже будет /public_html/ директория куда мы будем складывать результат. Всякое остальное на ваш выбор.

На локальном устройстве:

$ mkdir -p /tmp/hshhhhh.name/public_html/
$ cd /tmp/hshhhhh.name/
$ date > public_html/index.html
$ git init .
$ git config --local user.name "hshhhhh"
$ git config --local user.email "email"
$ git add public_html/
$ git commit -m "initial commit"

И посылаем это на удалённое устройство (если в урле есть : то это относительный путь, а если нет — абсолютный (но тогда должно начинаться с ssh://)):

$ git remote add hosting "hshhhhh.name:.git--bare/"
$ git push hosting

4. деплоим

Сначала мы git pull в локальный нормальный репозиторий, потом мы симлинкаем и как-нибудь там перезапускаем nginx если он вдруг не оценит подмену директории на симлинк.

Или на локальном устройстве, или на удалённом устройстве:

$ ssh hshhhhh.name "git clone ~/.git--bare ~/git/"
$ ssh hshhhhh.name "git -C ~/git/ pull"
$ ssh hshhhhh.name "cat ~/git/public_html/index.html"

Делаем симлинк и проверяем в браузере (при создании симлинка в конце не должно быть слеша):

$ ssh hshhhhh.name "mv ~/public_html/ ~/public_html_backup/"
$ ssh hshhhhh.name "ln -s ~/git/public_html/ ~/public_html"
$ curl --location https://hshhhhh.name/

4. деплоим обновление

На локальном устройстве:

$ cd /tmp/hshhhhh.name/
$ date >> public_html/index.html
$ git add public_html/index.html
$ git commit -m "second commit"
$ git push hosting
$ ssh hshhhhh.name "git -C ~/git/ pull"
$ curl --location https://hshhhhh.name/

Конец

Потрясающе, вы прямо хакер такие чудеса делаете может быть вам бы уже завести себе бложик и делиться вашими исследованиями?

#linux #howto #man #git #deploy

2025.11.10 04:05

Как точка файлы

Начало

В прошлом посте вы узнали про git --bare, а в этом вы узнаете зачем вы про это узнали.

В какой-то момент вашей жизни вам вдруг хочется чтобы одни и те же конфиги были на разных компьютерах и для этого вам их нужно с чем-то синхронизировать. Все как-то договорились что это делается через репозиторий с именем dotfiles.

В посте на реддите люди называют три способа.

1. gnu stow + git

Этот stow просто хранит всё в какой-то дирректории, а потом указывает туда симлинками, например:

 ~/.config/nvim/ > ~/.stow/.config/nvim/

Мне просто не нравится.

2. yadm: Yet Another Dotfiles Manager

Сложно!

3. git --blame

Можно случайно добавить самого себя, но можно и не добавлять.

Делаем ~/.dotfiles/

В том же посте рассказывают как всё делать и есть даже ссылка на блог (в котором нет rss!).

Я делаю всё так же как в этом блоге, но кладу гит на +1 уровень вложенности в ~/.dotfiles/git--bare/ и это даёт мне возможность добавить файл ~/.dotfiles/readme.md в котором я напишу как этим пользоваться.

Просто когда я это настраиваю в первый раз — мне несложно, а как потом этим пользоваться на втором устройстве? Я неумный, я не могу запомнить, мне нужно записать все шаги.

0. далёкий репозиторий

Создайте у себя в гитхабе приватный dotfiles репозиторий и найстройте ssh чтобы всё работало.

1. первый коммит

Создаём репозиторий, можете переименовывать всё как угодно

$ cd ~
$ mkdir -p ~/.dotfiles/git--blame/
$ git init --bare ~/.dotfiles/git--bare/
$ echo 'hello world' > ~/.dotfiles/readme.md

Делаем первый коммит, проверяем что всё работает

$ git --git-dir="$HOME/.dotfiles/git--bare/" --work-tree="$HOME" add ~/.dotfiles/readme.md
$ git --git-dir="$HOME/.dotfiles/git--bare/" --work-tree="$HOME" config set --local user.name "hello"
$ git --git-dir="$HOME/.dotfiles/git--bare/" --work-tree="$HOME" config set --local user.name "mail@example.com"
$ git --git-dir="$HOME/.dotfiles/git--bare/" --work-tree="$HOME" commit -m 'initial commit'
$ git --git-dir="$HOME/.dotfiles/git--bare/" --work-tree="$HOME" log

Если коммит случился — мы радуемся.

Но радуемся несильно потому что это больно и глупо. Создаём в рыбе функцию (ну или алиасьте там как умеете я не осуждаю):

  
$ cat ~/.config/fish/functions/dotfiles.fish

function dotfiles
    command git --git-dir="$HOME/.dotfiles/git--bare/" --work-tree="$HOME" $argv
end

Теперь у нас есть функция, её мы проверяем:

$ dotfiles status

Если вам стало неприятно от моего совета, то это хорошо! Теперь вызывая dotfiles мы как бы вызываем git, но со странными параметрами.

Теперь мы можем отключить показ недобавленных файлов:

$ dotfiles status
$ dotfiles config --local status.showUntrackedFiles not  
$ dotfiles status

2. синхронизация

$ dotfiles remote add github <url>
$ dotfiles push

3. безумие время

$ dotfiles add ~/.config/fish/
$ dotfiles commit -m '`~/.config/fish/`'
$ dotfiles push

Эмулируем второе устройство

Что выполнять на настоящем втором устройстве вы найдёте ниже, а тут мы проверим что всё работает на этом же устройстве. И убедимся что мы понимаем как это работает,
потому что если мы не понимаем мы могли бы пользоваться yadm например.

$ mkdir /tmp/dotfiles-sandbox/
$ cd /tmp/dotfiles-sandbox/
$ git clone --bare <url> /tmp/dotfiles-sandbox/.dotfiles/git--bare/
$ git --git-dir="/tmp/dotfiles-sandbox/.dotfiles/git--bare/" --work-tree="/tmp/dotfiles-sandbox/" reset --hard
$ ls

Если файлы внезапно появились, то мы всё сделали правильно. Теперь делаем коммит:

$ git --git-dir="/tmp/dotfiles-sandbox/.dotfiles/git--bare/" --work-tree="/tmp/dotfiles-sandbox/" config --local status.showUntrackedFiles no;
$ git --git-dir="/tmp/dotfiles-sandbox/.dotfiles/git--bare/" --work-tree="/tmp/dotfiles-sandbox/" config set user.name "temp"
$ git --git-dir="/tmp/dotfiles-sandbox/.dotfiles/git--bare/" --work-tree="/tmp/dotfiles-sandbox/" config set user.email "temp"

$ date >> /tmp/dotfiles-sandbox/.dotfiles/readme.md
$ git --git-dir="/tmp/dotfiles-sandbox/.dotfiles/git--bare/" --work-tree="/tmp/dotfiles-sandbox/" add /tmp/dotfiles-sandbox/.dotfiles/readme.md
$ git --git-dir="/tmp/dotfiles-sandbox/.dotfiles/git--bare/" --work-tree="/tmp/dotfiles-sandbox/" commit -m '`.dotfiles/readme.md`'  
$ git --git-dir="/tmp/dotfiles-sandbox/.dotfiles/git--bare/" --work-tree="/tmp/dotfiles-sandbox/" push

Если всё работает то всё работает.

$ rm -Rf /tmp/dotfiles-sandbox/

мы завтрашние

Вам может быть непонятно зачем это если на втором устройстве ничего не настроено, но:
1. вы можете посмотреть это файл прямо в гитхабе
2. вы всё равно должны как-то передать урл на второе устройство и настроить там ssh

А если у вас там всё это работает, то вы всегда можете сделать:

$ git clone <url> /tmp/dotfiles-temp/
$ cat /tmp/dotfiles-temp/.dotfiles/readme.md
$ rm -Rf /tmp/dotfiles-temp/

Вот вам содержимое ~/.dotfiles/readme.md, вы его поменяйте, поменяйте, сохраните и запушьте сами.

```
### init, first machine

$ mkdir -p ~/.dotfiles/git--blame/
$ git init --bare ~/./dotfiles/git--bare/
$ echo 'hello world' > ~/.dotfiles/readme.md

$ git --git-dir="$HOME/.dotfiles/git--bare/" --work-tree="$HOME" add ~/.dotfiles/readme.md
$ git --git-dir="$HOME/.dotfiles/git--bare/" --work-tree="$HOME" config set --local user.name "hello"
$ git --git-dir="$HOME/.dotfiles/git--bare/" --work-tree="$HOME" config set --local user.name "mail@example.com"
$ git --git-dir="$HOME/.dotfiles/git--bare/" --work-tree="$HOME" commit -m 'initial commit'
$ git --git-dir="$HOME/.dotfiles/git--bare/" --work-tree="$HOME" log

# fish function / alias

$ cat ~/.config/fish/functions/dotfiles.fish

function dotfiles
    command git --git-dir="$HOME/.dotfiles/git--bare/" --work-tree="$HOME" $argv
end

# check function / alias and hide new files notifications

$ dotfiles status
$ dotfiles config --local status.showUntrackedFiles not
$ dotfiles status

# add remote

$ dotfiles remote add github <url>
$ dotfiles push

# add first config

$ dotfiles add ~/.config/fish/
$ dotfiles commit -m '`~/.config/fish/`'
$ dotfiles push
```

```
### second machine

# be smart, create fish function / alias first

$ cat ~/.config/fish/functions/dotfiles.fish

function dotfiles
    command git --git-dir="$HOME/.dotfiles/git--bare/" --work-tree="$HOME" $argv
end


# deploy, but be careful: you can ruin existing files. Handle it somehow, I won't fight your internal coflicts!

$ git clone --bare <url> ~/.dotfiles/git--bare/
$ dotfiles status
$ dotfiles config --local status.showUntrackedFiles not
$ dotfiles status
$ dotfiles config set --local user.name "hello 2nd machine"
$ dotfiles config set --local user.name "mail@example.com"
```

Конец

Поздравляшки, теперь вы нерд!

#linux #howto #man #dotfiles #git

2025.11.10 00:31

git vs git --bare

Ваш гит репозиторий может существовать в двух вариантах: обычный и --bare. Обычный это ~гит-клиент, а необычный это ~гит-сервер. Ну то есть как бы нет, но --bare существует чтобы его как remote использовали обычные репозитории. И в нём ещё нет файлов.

Вы можете на своём впс создать --bare репозиторий и через ssh в него синхронизироваться не используя никаких сервисов вроде гитхаба. И каждый у кого будет ssh доступ тоже сможет его использовать как remote.

Почему-то когда создаёшь обычный, то он для себя создаёт отдельную директорию /.git, а когда --bare то он указанный путь использует как .git.

> git init  ./git-normal/
    Initialized empty Git repository in /tmp/.dotfiles/git-normal/.git/
> git init --bare ./git-bare/
    Initialized empty Git repository in /tmp/.dotfiles/git-bare/

> ls -lah git-normal/
    .git/
> ls -lah git-bare/
    hooks/
    info/
    objects/
    refs/
    HEAD
    config
    description

Смешная шутка: если вы положите --bare в ./.git/, то оно будет выглядеть как будто бы ./ тут есть гит, и он даже есть, но его нет!

fatal: this operation must be run in a work tree

#linux #howto #man #git

english version

2025.11.09 20:36

arch & pacman & etc-update

# pacman -Sy
:: Synchronizing package databases...
 core is up to date
 extra is up to date
 multilib is up to date
error: failed retrieving file 'core.db' from mirrors.nic.cz : The requested URL returned error: 404
error: failed retrieving file 'extra.db' from mirrors.nic.cz : The requested URL returned error: 404
error: failed retrieving file 'multilib.db' from mirrors.nic.cz : The requested URL returned error: 404
warning: too many errors from mirrors.nic.cz, skipping for the remainder of this transaction

оказывается, если pacman при установке пакета видит конфликты в конфигурационных файлах, то он создаёт рядом файл с апдейтом mirrorlist.pacnew и его потом можно смержить с используемым при помощи гентовской утилиты etc-update

КОГДА ТЫ ДУМАЕШЬ ЧТО ЭТО ДНО, НО СНИЗУ ПОСТУЧАЛА ГЕНТА

Вообще, конечно, странно в этом арче. Гента при каждом вызове emerge будет тебе рассказывать что у тебя есть новые конфигурационные файлы и с ними надо что-то сделать. А pacman просто падает вместо того чтобы смержить /etc/pacman.d/mirrorlist. Пришлось несколько раз дакдакгоить только чтобы узнать что надо проверить mirrorlist чтобы подакдакгоить что делать с этим mirrorlist.pacnew.

#linux #arch #gentoo #why

2025.10.19 22:42

Steam, игры и линукс

Несмотря на то что главная заслуга стима в линуксе — это популяризация линукса (особенно среди производителей), главным достижением в линуксе я выбираю протон.

Прошли годы, а в Valve не смогли победить линукс — через протон всё работает лучше чем в нативных версиях (потому что нативные версии игр никогда не работают).

(интересно как там на стимдеке, тоже всё через протон?)

#linux #games #valve #steam

2025.10.19 19:36

Локальный распределенный DNS без DNS: Multicast DNS (mDNS)

Введение


У вас есть два линукс изделия (другие тоже будут работать, но вам надо гуглить зачем) между которыми вы ходите уметь общение.

Самый простой вариант это по ip, но только один раз. Завтра изделие получит другой ip и это никак не победить.

Самый простой вариант это добавить в /etc/hosts файл алиас:

192.168.0.48 destination

А во всех скриптах использовать алиас, например:

$ scp kitty.gif user@destination:

Но ip всё равно меняется. Но менять уже в одном месте. Но менять всё же надо.

Самый просто вариант это починить это установить локальный DNS сервер на сервере и сделать его главным в сети и проксировать все запросы через него нет такого.

А ведь было бы здорово не менять это вручную да?

Multicast DNS (mDNS)


В 2025 году 25 лет назад придумали Multicast DNS (mDNS) который через бродкаст запросы делает динамический распределённый локальный DNS о котором не надо беспокоиться и который просто работает. Но только в одной сети. И только один хост на изделие.

Как Multicast DNS (как mDNS)


В линуксе оно когда конвертирует слова-имена в цифры оно делает через сервис Name Service Switch. У этого сервиса есть /etc/nsswitch.conf где ему указано где как искать:

> cat /etc/nsswitch.conf
# Name Service Switch configuration file.
# See nsswitch.conf(5) for details.

passwd: files systemd
group: files [SUCCESS=merge] systemd
shadow: files systemd
gshadow: files systemd

publickey: files

hosts: mymachines resolve [!UNAVAIL=return] files myhostname dns
networks: files

Для хостов оно говорит сначала искать в (mymachines) в локальных контейнерах.

Потом оно ищет в (systemd-resolved) dns который заменил собой nss-dns. Если DNS возвращает недоступно, то конец, не искать.

Потом смотрит в /etc/hosts, на локальный хостнейм и потом уже в легаси DNS.

Занимательный факт: мы можем добавить ещё сервис в этот лист. Что если мы добавим Multicast DNS (mDNS)?

Установка Multicast DNS (установка mDNS)

Совершенно абсолютно очевидно что на каждом изделии мы будем делать и серверную, и клиенсткую части. Поэтому всё что ниже нужно сделать везде чтобы была гармония.

https://wiki.archlinux.org/title/Avahi

Устанавливаем пакет libnss-mdns в котором будет avahi (мы добавим в NSS hosts как сервис):

# pacman -Sy nss-mdns
# emerge -av sys-auth/nss-mdns
# sudo apt-get install libnss-mdns avahi-daemon avahi-utils

Дальше добавим /etc/nsswitch.conf строку mdns_minimal [NOTFOUND=return]:

# hosts: mymachines resolve [!UNAVAIL=return] files myhostname dns
hosts: mymachines mdns_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] files myhostname dns
# hosts: mymachines mdns_minimal resolve [!UNAVAIL=return] files myhostname dns

[NOTFOUND=return] говорит не искать дальше домены *.local, это сломает (вероятно) локальные записи в /etc/hosts поэтому можно удалить чтобы работало как раньше, но лучше.

Ещё можно перехватывать на только *.local домены, но нам это не нужно. Для этого мы будем использовать /etc/hosts

Устанавливаем наш локальный домен в файле /etc/avahi/avahi-daemon.conf и перезапускаем и проверяем:

$ cat /etc/avahi/avahi-daemon.conf | grep host-name

host-name=source

$ systemctl enable avahi-daemon.service # add to autorun
$ systemctl restart avahi-daemon.service # run

$ avahi-browse --all --verbose --resolve --terminate

$ avahi-resolve-host-name source.local

source.local	192.168.100.101
  
$ ping source.local

PING source.local 56 data bytes
64 bytes from source.local : icmp_seq=1 ttl=64 time=0.031 ms
64 bytes from source.local : icmp_seq=2 ttl=64 time=0.067 ms
64 bytes from source.local : icmp_seq=3 ttl=64 time=0.056 ms
^C

Проблема в том что у нас может быть 1 хост на одно изделие. Если вы хотите поднимать несколько разных локальных доменов например:

git.local
server.local

То это можно легко сделать через /etc/avahi/hosts, но там тоже надо хардкодить ip.

Самый простой способ это починить это при поднятии сети запускать несколько раз avahi-publish & на каждый домен каждый раз вычисляя динамически локальный ip а никак живите с одним доменом всё лучше чем ничего.

Включаем sftp/ssh


$ cp /usr/share/doc/avahi/sftp-ssh.service /etc/avahi/services/
$ cp /usr/share/doc/avahi/ssh.service /etc/avahi/services/

$ systemctl restart avahi-daemon.service

Второе изделелие


Быстренько повторяем всё что сверху на втором изделии, потом ищем их друг у друга проверяем что всё работает. Настраиваем ssh подключение по ip между двумя изделиями. Потом в ssh просто меняем ip на локальный домен:

$ ssh my_user@destination.local -i ~/.ssh/my_key

Когда всё работает мы добавляем ~/.ssh/config эти волшебные слова:

Host destination
    HostName destination.local
    IdentityFile ~/.ssh/my_key
    User my_user

Магическим образом был создан короткий алиас для ssh в котором всё настроено:

$ ssh destination

Ну вот и всё, теперь мы можем легко обмениваться файлами и удалённо запускать команды:

$ cd /tmp/
$ date > temp_file
$ echo "source" >> temp_file
$ scp temp_file destination:
$ ssh destination 'echo destination >> ~/temp_file'
$ ssh destination 'cat ~/temp_file'

Уру-ру-ру, мы можем посылать файлы и удалённо выполнять команды. А главное теперь есть домены не привязанные к ip!

Выведение


Главный для меня минус в том что нельзя просто сделать несколько доменов на много сервисов на одном изделии, но с этим можно жить!

Зато таким же образом можно сделать и NFS, и rsync, и git!!!

А ещё mDNS используется в IoT и прочих home assistant сетей!

#linux #multicastdns #mdns #dns #howto #man

english version

2025.09.28 01:53

Arch, Rar & Aur

Install the rarAUR package for both RAR and UnRAR, unrar for just UnRAR, or unrar-free for a FOSS implementation of unrar.

Хочешь рар, хоти и аур!

#arch #aur #linux

2024.12.10 14:03

An Unreliable Guide to XKB Configuration by Doug Palmer

Если вы не знаете что почитать перед сном, но мечтаете о приятном, смешном и успокаивающем чтении, то я могу порекомендовать вам An Unreliable Guide to XKB Configuration by Doug Palmer. Очень, очень приятно написано, полно искромётного юмора, неожиданный сюжет и потрясающие главные герои.

#manual #happyreading #linux #xkb

2024.03.17 23:43

Gentoo & binary packages

Разработчики проекта Gentoo объявили о введении в строй отдельного репозитория с бинарными пакетами, собранными с поддержкой третьей версии микроархитектуры x86-64 (x86-64-v3), применяемой в процессорах Intel примерно с 2015 года

Новый репозиторий позволяет добиться более высокой производительности на современных процессорах, благодаря задействованию в программах расширенных инструкций.

Приятно видеть что мейнтейнеры генты не предают идеи генты!

#gentoo #linux #why #wtf

2024.02.08 00:44

arch ▯ шрифты

Традиционно, шрифты это ад и ненависть. Как настраивать fontconfig понимают только те кто понимают, но я не из тех кто пониимает и поэтому не понимаю. При каждой попытке занырнуть в этот xml я понимаю что не стоило этого делать.

Каким-то образом понаставив каких-то пакетов наугад удалось найти какой-то моноширинный шрифт на который больно смотреть, но всё же можно смотреть. Это была победа.

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

Но после очередного обновления прекрасного прекрасного rolling release эмодзи стали показываться не все, но зато чёрно-белые. И всё, как это починить непонятно.

Доколе.

#arch #linux #fonts #emoji #hate #why #wtf

2024.02.08 00:43

Linux and named ports

А вы знаете что в линуксах есть файл /etc/services и в него можно добавить алиасы для портов? Напрмер:

# tail -n 1 /etc/services
docker-git-http 23456/tcp

Ну, знаете, удобно не хардкодить везде какие-то числа которые потом невозможно поменять, а просто пишешь алиас и везде используешь. Ну, прямо как с /etc/hosts и всякими локалхостами! Очень удобно!

Только именованные порты не работают ни в nginx, ни в docker.

Как? Почему? Кто виноват? Как жить с этой печалью?

#linux #wtf #sob

2024.01.03 14:35

sway vs awesome

В целом sway вполне себе замена для awesome, но не то чтобы он awesome.

sway:
+ перезагрузка конфигурации на лету просто работает, и даже перезагружает конфигурацию waybar, очень клево работает. В awesome тоже работало, но оно теряло конфигурацию воркспейсов и надо было снова перераспределять окна. Бесило неимоверное и никогда не хотелось “поменять 1 символ и релоднуть конфигурацию”.
+ может выглядеть почти как awesome что awesome
+ нормальное распределение окон, в awesome сценарии были какой-то хернёй, так и не получилось к ним привыкнуть.
– нет нормального способа избавиться от window header, всегда есть две полоски: waybar + window header. Люди советуют это всё запихнуть в waybar чтобы было как в awesome, но что-то мне пока не хочется пробовать — в стандартной конфигурации окна можно двигать в этом “типа таскбаре” (который на саомм деле просто объедененный window header) и это великолепно.
+- swaybar херня, сразу в утиль, но зато waybar солнышко и лапонька. Стандартные виджеты даже лучше чем в awesome и это awesome!

#linux #x11 #wayland #sway #awesome

2023.12.07 15:16