…как и весь линукс в целом.
пруф: https://ibb.co/dJV7wwqs

аж 930 мВт потребления энергии, куда дело годится?
не готов для десктопа, пойду последую примеру @seiken и поставлю винду.

девайс, кстати, Microsoft Surface.
на родной дрисняточке потребление в простое ~5W, ага.

привет, ЛОР.
вопрос к знатокам, а то я чёт туплю.

вот допустим я включил секурбут, подписал ядро+initrd своим ключиком, который добавил в UEFI.
таким образом, по идее, защищаются от несанкционированной загрузки другой ОС?

но ведь злоумышленник может в том же UEFI отключить secure boot и загрузить что угодно.
пароль на биос? он разве не сбрасывается перемычкой/обесточиванием на ноуте?

как это вообще должно работать и от чего защищать? требуется пояснительная бригада.
ненужнист фирфокс @firkax не нужен.

Понадобилось тут завести модем с eSIM в онтопике. Использовал модем Qualcomm® Snapdragon™ X16 LTE Modem на планшете Microsoft Surface Go 2 на Debian GNU/Linux 13 (trixie).

( читать дальше... )

Перемещено hobbit из desktop

добрый вечер в хату, ЛОР.
у меня тут такой вопрос возник: а есть ли в 2025 какие-то сервисы а-ля last.fm, но без необходимости отскроббливать всю свою локальную коллекцию?

хочется получить список рекомендованных к прослушивнию исполнителей на основании списка исполнителей/альбомов.
что я пробовал: собственно last.fm (да, он всё ещё живой), spotify, apple music, google music – самое близкое к тому, что я хочу – ВНЕЗАПНО, apple music, но работает оно через жопу и только на яблоках.
во всех остальных стриминговых сервисах по какой-то причине рекомендации просто ломаются и начинают в лучшем случае рекомендовать тупо рандом внутри жанра (причём и Metallica и Linkin Park считаются условным «роком», хотя оно вообще про разное), а в худшем – другие композиции тех исполнителей, которые уже есть в плейлисте.

итого таким образом было найдено полтора новых исполнителя (релевантных моему вкусу), результат так себе.
last.fm показал себя лучше – с пятóк коллективов точно нашлось.

лучший результат показала LLM (конкренее – гопота), которой скормили выхлоп ls /data/music.
в связи с чем возник вопрос: неужели в 2025 не придумали сервиса (не обязательно стриминг), которые используя все возможности искуственных болванчиков могут предложить что-то интересное послушать?

во влажных фантазиях, конечно, хочется чтобы оно умело скачивать/стримить музыку со всех популярных P2P «магазинов», но это было бы слишком хорошо, оставим это как идею для стартапа.

Привет, ЛОР.
Хочу поделиться историей успеха от избавления от эпплозависимости методом козы в комнате.

На игле я примерно с 2023, когда приказал долго жить последний Blackberry.
Android даже не рассматривал, потому что ведро для меня всегда было дырявым решетом, которое все еще воняет опенсорсом, но при этом уже анально огорожено.
Из двух зол было выбрано меньшее – яблозонды хотя бы более безопасны (не путать с прайваси!) и не так чувствуется привкус опенсорса, который даже в топовых Самсуанях просачивается то здесь, то там.

Мыши плакали и кололись два с лишним года, пока в очередной раз не наткнулись на упоминание GrapheneOS.
Для экспериментов был заказан старый Пихель (7) за две пачки доширака.

Без всяких ожиданий я накатил ROM, и каково же было мое удивление!
Кроме шуток, топовый гейфон 100500 про за почти две тыщи уже отправлен на помойкуместное авито.

Приватность, безопасность, надежность, предсказуемость, открытость, время работы от батареи. И усе сразу! Еще и выглядит не как говно, после пары лет с айфоном это важно.
Да, кстати, к кастомным прошивкам я тоже всегда был предвзят – никогда они не работали лучше стока (а во многом хуже), несмотря на то, что тянули потроха (ядро и драйвера) из родной фирмвари. Но нет, тут все наоборот: время работы от аккумулятора и стабильность работы намного лучше, чем на стоковом ведре!

Такие дела. Задавайте свои ответы.

Время 4:20, а значит настала пора чудесных историй.

Волей случая был вынужден достать запасной Thinkpad X270, и я внезапно решил накатить OpenBSD.

Система отличная, всё железо ноутбука успешно определено и работает, даже LTE (см. второй скриншот)
Wi-Fi работает в режиме 802.11ac, выдаёт полные 200 мегабит, которые даёт оператор.

Спящий режим и гибернация работают из коробки. Батарею во сне ест достаточно медленно, хватает на четверо суток. К сожалению, гибридный сон не нашёл как включить – может как-то и можно.

( читать дальше... )

После обновления на Debian 13 в некоторых программах отобржается очень маленький курсор мыши.
От тулкита не зависит (Gtk/Qt), от способа установки тоже (apt/flatpak).

Примеры: нормальный курсор / мелкий курсор
И Thunar, и Firefox используют Gtk3.

Также нормальный курсор в: Gajim (Gtk4), Geany (Gtk3), Xfce4-terminal (Gtk3)
Маленький курсор: Audacious (Qt), Firefox (Gtk3), Thunderbird (Gtk3), Telegram (Qt)

При увеличении размера курсора в панели Xfce и перезапуске софта курсор становится нормального размера, но только до перезапуска сессии.
Не критично, но немного бесит, куда копать? inb4: в багтрекер

это НЕ wayland, это X11.
upd: возможно, курсор ломается после запуска любой софтины из Flatpak, но это пока не точно.

Обновился до Trixie на ноутбуке, ничего не поломалось.

На скриншоте экзотический ноутбук Fujitsu U9313X с хорошими характеристиками.
К сожалению, за год батарея деградировала до 80%, и ноутбук держит всего 12 часов вместо 16.

Буду менять на такой же новый – как раз закупил пару штук из последней партии в Европе. Ноуты очень дешёвые (1200€ без НДС), но, к сожалению, Fujitsu закрыла представительство в Европе и теперь их только заказывать и импортировать из Японии. Печалька.

Кстати, ноутбук поддерживается в Linux на 99% (не работает биометрия, фирменный сканер вен). Такие дела.

Коллеги, добрый день!
Нужна помощь по конфигу nginx’а.

Задумка следущая: «всё то, что идёт в апстрим (не статика), лимитируется 1000 запросами в минуту на уникальный IP адрес, остальные запросы уходят в статус 556»

limit_req_zone $binary_remote_addr zone=main:30m rate=1000r/m;

location / {
    try_files $uri @upstream;
}
    
location @upstream {
    limit_req zone=main;
    limit_req_status 556;
    ...
}

Проблема следущая: рандомные запросы бодро улетают в 556, при этом всего от IP-адреса, который улетел в 556, 36 запросов ЗА СУТКИ (!):

{"remote_addr":"51.79.xxx.xx","remote_user":"-","time_local":"21/May/2025:08:09:50 +0000","host":"host.name","request":"GET / HTTP/2.0","status":"556","body_bytes_sent":"0","http_referer":"-","http_user_agent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/136.0.0.0 Safari/537.36","request_time":"0.000"}

root@www7:~# grep 51.79.xxx.xx /var/log/nginx/host.name.access.log|wc -l
36

ЧЯДНТ?

update: подсказали про опцию burst, будем посмотреть.

Снова здравствуй, ЛОР!
На этот раз я к тебе по делу.

После внепланового ребута домашней машины с аптаймом в несколько месяцев обнаружил на логинскрине в GNOME странного пользователя.
В $HOME у этого пользователя была директория с китайским иероглифом в названии.

root@undercity:/root# ls /home/daapd/
模板

Отключил машину от интернета, стал разбираться.
Этого пользователя я создал сам, для одной софтины (owntone-server, бывш. daapd), однако, очевидно, никаких директорий в его хомяке не создавал, тем более с китайским иероглифом в названии.

Увидел в истории шелла запуск этой софтины от рута и подумал – ну всё, приехали.
Софт хоть и достаточно популярный, но после бэкдоров в xz уже никому и ничему не веришь.

Однако, сегодня обнаружился куда более интересный факт:

root@undercity:~# ls -l /home/hana/
total 153808
drwxr-xr-x 2 hana hana      4096 Jul  8  2022 laptop
drwxr-xr-x 3 hana hana      4096 Jun  9  2022 vanitygen
drwxr-xr-x 4 hana hana      4096 Jun  9  2024 vanitygen-plusplus
-rwxrwxrwx 1 hana hana 157475346 Jun  2  2024 zaberi_menja.zip
drwxr-xr-x 2 root root      4096 Feb 10 17:30 模板

root@undercity:~# ls -l /home/asxpi/
total 8
drwxr-xr-x 14 asxpi asxpi 4096 Dec 24 00:45 invidious
drwxr-xr-x  2 root  root  4096 Feb 10 17:30 模板

То есть, у всех пользователей в системе (upd: не у всех – у моего, например, не было) есть эта пустая директория с иероглифом в названии в хомяке.
Раскопки глубже показали наличие этой (пустой) директории с иероглифом в /etc/skel:

root@undercity:~# ls -la /etc/skel/
total 40
drwxr-xr-x   3 root root  4096 Feb 10 17:27 .
drwxr-xr-x 166 root root 12288 May  7 12:21 ..
-rw-r--r--   1 root root   220 Dec  8  2020 .bash_logout
-rw-r--r--   1 root root  3526 Dec  8  2020 .bashrc
-rw-r--r--   1 root root  5290 Apr 13  2023 .face
lrwxrwxrwx   1 root root     5 Jul 12  2023 .face.icon -> .face
-rw-r--r--   1 root root   807 Dec  8  2020 .profile
drwxr-xr-x   2 root root  4096 Feb 10 17:30 模板

Остальные файлы в /etc/skel не тронуты. Других признаков взлома нету. rkhunter не нашёл ничего.
В /var/log/auth.log ничего примечательного не обнаружено.

Из занимательного: я почти уверен, что в марте этого файла не было в /home/asxpi как минимум. (но не на 100% уверен, конечно же)
Из куда более занимательного: в хомяке лежали приватные ключи от криптокошельков общей суммой в несколько битков плейнтекстом – всё целое, ничего не пропало.

Что ещё посмотреть, прежде чем грохнуть систему?
Как вообще такое могло произойти?

Есть ли (хотя бы мизерный) шанс, что это следствие побитой ФС после аварийного отключения электричества, после которого и была обнаружена эта странная директория? (отключение было вчера, всё ещё вопросы как появилась директория с mtime = 10 Feb)

Систему в любом случае буду переустанавливать и сносить, как и инвалидировать все приватные ключи, естественно – интерес чисто спортивный, как же так вышло и как не допустить такого в дальнейшем.