Существуют ли нормальные CLI-/TUI-клиенты Subsonic?

Вопрос всё ещё актуален.

А ненормальные CLI/TUI у него есть?

А ненормальные CLI/TUI у него есть?

Нет. (%

Разучился гуглить? :)

https://git.sr.ht/~ser/ostui:

ostui is a terminal client for *sonic music servers, inspired by ncmpcpp and musickube.

На Go.

Разучился гуглить? :)

Никогда не умел. )=

sr.ht

Последнее место, где я стал бы искать. (=
Автор Sourcehut весьма упорот, и собрал вокруг себя таких же упорышей…

На Go.

Хоть что-то в этом мире ещё не на Rust… (%

Попробовал собрать…

# github.com/gen2brain/go-mpv
../../../go/pkg/mod/github.com/gen2brain/go-mpv@v0.3.1/client.go:7:10: fatal error: 'mpv/client.h' file not found
    7 | #include <mpv/client.h>
      |          ^~~~~~~~~~~~~~
1 error generated.

Как Go ткнуть носом в /usr/local/include?

/usr/local/include?

Просто лучший каталог для include.

github.com/gen2brain/go-mpv

Поглядел доку по той ссылке, как то странно написано.

...
Runtime Dependencies
...
Linux (Debian/Ubuntu): apt install pkg-config libmpv libmpv-dev
...

Я почему то в слово РАНТАЙМ всегда вкладывал другой смысл.

Всё что установлено из пакетов/портов, ставится в /usr/local.

Это ж не венда с линуксом, где всё в кучу.

Согласен.
Но имеем что имеем.

Либы-то у меня установлены (хедеры ставятся вместе с mpv). Сейчас devel/pkgconf установил, но ничего не поменялось.

с линуксом, где всё в кучу.

~ $ ls /usr/include/mpv/
client.h render.h render_gl.h stream_cb.h

Не надо юля-юля, нет никакой кучи.

нет никакой кучи

Видишь суслика? А он есть!

Не включай дурака. У тебя все хедеры в одном /usr/include, и ты в принципе не сможешь отделить мух от котлет.

Разучился гуглить? :)

Никогда не умел. )=

Печально.

Как Go ткнуть носом в /usr/local/include?

Попробуй $ CGO_CFLAGS="-I/usr/local/include" go build.

Либы-то у меня установлены (хедеры ставятся вместе с mpv). Сейчас devel/pkgconf установил, но ничего не поменялось.

хм. Не понял а gcc тоже что ли не находит их?

CGO_CFLAGS

То что надо, спасибо!

Но разницы-то нет, где куча: в /usr/include или в /usr/local/include.

Так собралось, работает? А то этих клиентов куча, и на Питоне есть. :)

Так собралось, работает?

Нет. (=

Ну удали /usr/include.

Удаление /usr/local/include у меня проблем не вызовет.

Нет. (=

Очень информативно! (нет)

Конечно же это вызовет проблемы, к чему эти глупости. Иначе зачем ты пытался указывать /usr/local/include компилятору, если у тебя отсутствие этого каталога проблем не вызывает.

В любом случае, для начала нужно обосновать применимость удаления */include.

а бины нельзя попробовать?

https://downloads.ser1.net/software/ostui/

У ТС freebsd. :)

Сделал библиотеку для работы с Subsonic API на Android

Можешь стартануть уже отсюда, там дальше закодить

Полез искать что это такое. А чем лучше Plex и прочей попсы?

У тебя все хедеры в одном /usr/include

И чё? Большая часть хедеров в своих именовых каталогах.

а бины нельзя попробовать?

Их там нет под мою ОС.

Можешь стартануть уже отсюда, там дальше закодить

Я очень плох в погромировании.

Не понял а gcc тоже что ли не находит их?

Не пробовал. Зачем ставить GCC, когда LLVM есть из коробки? Разве что если оно прибито гвоздями к.

Да и не знаю я как Go попросить использовать недефолтный компилятор/линковщик.

А чем лучше Plex и прочей попсы?

У Plex свой протокол и свои клиенты, а Subsonic это открытый (ну почти) стандарт стриминга музыки, для которого есть куча серверов и клиентов, и все они будут работать друг с другом.

У меня эта же музыка доступна через Jellyfin, но у него тоже свой протокол, а клиентов к нему всего полтора, и все на iOS/Android. Десктопных вдвое меньше, и те не работают. (%

Попробуй добавить: LDFLAGS=-L/usr/local/lib.

Да, в топик приглашается @kaldeon. :)

Скорее CGO_LDFLAGS

LDFLAGS=-L/usr/local/lib

Ничего не поменялось:

# ser1.net/ostui
/usr/local/go126/pkg/tool/freebsd_amd64/link: running cc failed: exit status 1
/usr/bin/cc -m64 -Wl,--build-id=0xa8fca0a35bc69abff81e696cab32af988426315f -o $WORK/b001/exe/a.out -Wl,--export-dynamic-symbol=__progname -Wl,--export-dynamic-symbol=_cgo_panic -Wl,--export-dynamic-symbol=_cgo_topofstack -Wl,--export-dynamic-symbol=crosscall2 -Wl,--export-dynamic-symbol=environ -Qunused-arguments -Wl,--compress-debug-sections=zlib /tmp/go-link-1691772372/go.o /tmp/go-link-1691772372/000000.o /tmp/go-link-1691772372/000001.o /tmp/go-link-1691772372/000002.o /tmp/go-link-1691772372/000003.o /tmp/go-link-1691772372/000004.o /tmp/go-link-1691772372/000005.o /tmp/go-link-1691772372/000006.o /tmp/go-link-1691772372/000007.o /tmp/go-link-1691772372/000008.o /tmp/go-link-1691772372/000009.o /tmp/go-link-1691772372/000010.o /tmp/go-link-1691772372/000011.o /tmp/go-link-1691772372/000012.o /tmp/go-link-1691772372/000013.o /tmp/go-link-1691772372/000014.o /tmp/go-link-1691772372/000015.o /tmp/go-link-1691772372/000016.o /tmp/go-link-1691772372/000017.o /tmp/go-link-1691772372/000018.o /tmp/go-link-1691772372/000019.o /tmp/go-link-1691772372/000020.o /tmp/go-link-1691772372/000021.o /tmp/go-link-1691772372/000022.o /tmp/go-link-1691772372/000023.o /tmp/go-link-1691772372/000024.o -O2 -g -lmpv -O2 -g -O2 -g -lpthread -O2 -g -O2 -g -no-pie
ld: error: unable to find library -lmpv
cc: error: linker command failed with exit code 1 (use -v to see invocation)

Я не (настолько) тупой, но башка трещит так, что я плохо соображаю.

@dataman и @kaldeon, спасибо вам. (=

Теперь осталось разобраться, как подключиться. (%

Я вообще никакой погромист, только вот сборка к программированию отношения вообще не имеет.

Я вообще никакой погромист, только вот сборка к программированию отношения вообще не имеет.

А ничего что по ссылке штука под Android, а у меня далеко совсем не он?

Сорян, Борян! Промахнулся.

Теперь осталось разобраться, как подключиться. (%

Там же в README есть пример:

Configuration
ostui looks for a configuration file named config in either $HOME/.config/ostui or the directory containing the executable.

#Example Configuration
Often, the command line arguments can be stuffed into the config file.

[auth]
username = 'admin'
password = 'password'
plaintext = true  # Use 'legacy' unsalted password authentication (default: false)

[server]
host = 'https://your-subsonic-host.tld'

Не включай дурака. У тебя все хедеры в одном /usr/include, и ты в принципе не сможешь отделить мух от котлет.

А каких мух от каких котлет ты собрался отделять в линуксах? Ну ок, во фряхе есть «порты», и из них всё ставится в /usr/local. В линуксах портов нет, есть репозитории, все пакеты ставятся из репозитория. Тоже в одно место. Что и от чего тут отделять? Тут тоже есть отделение, только по другому признаку: пакетный менеджер ничего не кладёт в /usr/local, а админ ручками наоборот — всё кладёт именно в /usr/local (кроме того, для чего лучше подходит /opt) b ничего не кладёт в /usr за пределами local. Вот тебе и отделение мух от котлет.

[auth]
...
password = 'password'

То, что пароль надо хранить в открытом виде — уже плохо. Даже если сделать файл -r--------, это не панацея.

Но проблема не в этом. Оно подключается очень долго, а потом начинает воспроизведение очень долго и в целом тупит при навигации.
Используемый на данный момент supersonic (тоже на Go, но GUI) работает ощутимо быстрее.

А каких мух от каких котлет ты собрался отделять в линуксах?

Ну хотя бы системные библиотеки от некритичных.

Хотя чего это я… у вас и системы-то никакой нет, просто кучка разношёрстного софта, склеенного изолентой (даже не всегда синей!). (%

> То, что пароль надо хранить в открытом виде — уже плохо

А как вы бы решили эту проблему? При условии, что мы не можем привязываться к OpenPGP или GNOME Keyring. OpenSSL (чтобы ограничить доступ к ключу только пользователю процесса)?

Ну хотя бы системные библиотеки от некритичных.

Это как? По какому признаку будем определять критичность? Или типа glibc/musl отдельно, и там же ядро, а всё остальное отдельно? И… зачем?

Хотя чего это я… у вас и системы-то никакой нет, просто кучка разношёрстного софта, склеенного изолентой (даже не всегда синей!). (%

Да, «система» — это совокупность разношёрстного софта, всё верно. Это и минус и плюс одновременно, тут уж кому как. Но именно поэтому и никакое отделение «системных» библиотек от «несистемных» тут смысла и не имеет, это во фряхе понятно, что есть «система», а есть «порты», в линуксах такого нет. Ну точнее в каком-то смысле есть, конечно: «система» это всё что из реп, пакетным менеджером установлено, а «не система» — это то, что админ руками понаписал, понакачал, понатырил у других админов, или понаставил через make install. Если так взглянуть на это разделение, то вот точно так же и получается, что «система» вне local, а «не система» — в /usr/local, и всё как раз таки отделено.

мы не можем привязываться к OpenPGP или GNOME Keyring

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

А как вы бы решили эту проблему?

Ну, например, как это сделали msmtp или isync: Там можно указать passwordeval/PassCmd вместо пароля, и оно вызовет нужную команду и заберёт пароль из stdout. UNIX-way! А какую программу для этого использовать — это уже каждый сам выберет.

Нормальный - это какой?

Удали /usr/local и напиши сюда, как хорошо работает твоя «система».

Это как? По какому признаку будем определять критичность?

Если без определённых библиотек ОС не загружается и/или не даёт себя исправить в интерактивном режиме — они критичные.

Да, во фряхе есть статически слинкованный набор софта в /rescue, на случай совсем уж котострофы, но я не припомню, чтобы он хоть раз понадобился. (=

Да, «система» — это совокупность разношёрстного софта, всё верно. Это и минус и плюс одновременно, тут уж кому как.

Ну объективно это минус. Во фряхе это тоже разношёрстный софт, но он хотя бы проходит аудит и патчится (под нужды системы) одной командой разработчиков с общим видением, прежде чем попасть в систему. Не идеально, но стабильно.

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

Софт из портов может в моменте не собраться (потому что мейнтейнер одной из зависимостей не успел запушить обновления, а нужная тебе софтина уже на них расчитывает). В роллинговых линуксах такая ситуация тоже возможна, потому что подход тот же: куча независимых мейнтейнеров без строгой координации (и особого контроля) поддерживают то, что нужно лично им.

Ну точнее в каком-то смысле есть, конечно: «система» это всё что из реп, пакетным менеджером установлено

По такому принципу и какой-нибудь toilet, cowsay и fortune — "система". (%

Но я не об этом. Вот, допустим, юзер совсем балбес, без опыта, без понимания, он не хочет разбираться и/или ему просто некогда. Он спросит у какого-нибудь ChatGPT, и оно ему случайно предложит команду, удаляющую glibc или ядро, с флагом, чтобы менеджер пакетов не спрашивал подтверждения. И ой.
Или чуть другой сценарий: удалить какой-нибудь NetworkManager из попсового дистрибутива. Всё, обратно его уже не установить — сети нет.

Во фряхе можно удалить вообще все пакеты/порты, даже сам менеджер пакетов можно удалить. И это не превратит систему в тыкву. Да, она перестанет выполнять часть поставленных ей задач, требующих софта из пакетов/портов, но всё можно вертать взад штатными средствами, без всяких LiveUSB, Single User Mode и прочего. Впрочем, pkgbase уже на этапе публичного тестирования, так что скоро у нас будут те же проблемы, что и у вас. (%

а «не система» — это то, что админ руками понаписал, понакачал, понатырил у других админов, или понаставил через make install.

А к чему отнести всякие PPA, AUR и прочие оверлеи и пользовательские репозитории? Из них софт ставится в общую кучу обычно.

Я не утверждаю что фряха идеальна, но в некоторых вопросах она чуточку лучше. Потому что UNIX-way.

Существуют ли нормальные CLI-/TUI-клиенты Subsonic? (комментарий)

По такому принципу и какой-нибудь toilet, cowsay и fortune — «система». (%

Естественно. Если они из реп поставлены, конечно.

Но я не об этом. Вот, допустим, юзер совсем балбес, без опыта, без понимания, он не хочет разбираться и/или ему просто некогда. Он спросит у какого-нибудь ChatGPT, и оно ему случайно предложит команду, удаляющую glibc или ядро, с флагом, чтобы менеджер пакетов не спрашивал подтверждения. И ой.

Если юзер совсем балбес, он может и тупо sudo rm -rf / сделать.

Или чуть другой сценарий: удалить какой-нибудь NetworkManager из попсового дистрибутива. Всё, обратно его уже не установить — сети нет.

Приехали, теперь уже и всякие NetworkManager — «система»?..

Не, это странный подход и попытка разделить пакеты на важные и неважные по какому-то очень мутному критерию. Я вот не пользуюсь NetworkManager, пару раз потыкал где-то в нулевых, не особо понял, нафиг оно нужно (хотя, говорят, на ноутах при постоянной смене wifi удобно, хз), и больше никогда не ставил. А кто-то, наверное, и правда считает его важным. Но кто-то другой посчитает важным, скажем, нормальный текстовый редактор (типа без него тоже нельзя восстановить систему в случае чего, а какой-нибудь sed не для всех), а ещё кто-то вообще иксы с вяленым. Субъективщина это всё, нет чёткого критерия, и не нужно такое разделение на уровне дистрибутива.

Я понимаю, как это работает во фряхе, и там это действительно имеет смысл. Но в линуксе не так, не надо сюда пытаться притащить тот же подход. Здесь он другой, и это по своему замечательно. Лучше же, когда есть разные системы, а не все под копирку.

А к чему отнести всякие PPA, AUR и прочие оверлеи и пользовательские репозитории? Из них софт ставится в общую кучу обычно.

Ну разве что вот это можно было бы отделить. Но можно и не отделять, ибо не очень понятно, зачем. А главное, куда тогда лазить ручками админу, и куда совсем не лезет пакетный менеджер? Разве что ещё один слой создать, /usr/local/local, или типа того, тогда будет иметь смысл, наверное. Ну или сделать /local и /usr/local, чтобы совсем уж матрёшек не городить. В таком виде идея даже интересная. Но если её не реализовывать, и принять как данность, что есть всего два «уровня», я всё же предпочту как есть — пускай пакетный менеджер хозяйничает в /usr, а админ ручками — в /usr/local, как по мне, это несколько полезнее, чем отделять AUR/PPA.

Опять же, повторюсь, во фряхе такой подход имеет смысл, и именно там я его не критикую. Просто он как-то плохо натягивается на GNU/Linux.

P.S. Есть ещё вариант сильно revamp’нуть FHS наконец, а на практике убрать эти дурацкие симлинки /bin и /lib из нынешних линуксов, а из /usr всё перенести в корень, то есть чтобы было /bin, /lib, /share, /include, /src и /local. Для совместимости с захардкоженными путями в скриптах добавить симлинк /usr→/. Было бы как-то аккуратнее, упорядоченнее что ли — /usr нынче не выполняет в линуксах никакой задачи, он просто так есть. И вот тогда стало бы вполне элегантно — пакеты из реп лезут везде, кроме /local (и возможно /opt), всякие AUR/PPA можно в /local, а админ ручками в /local/usr или типа того. Я вообще не очень понимаю, зачем вот это нагородили с убиранием всего в /usr и добавлением симлинков в корень — раз уж смешали /bin, /usr/bin, /sbin и /usr/sbin все в кучу — надо было наоборот в логичный и понятный /bin всё это сложить, аналогично с /lib, ну и остальное уж по пути из /usr вытащить. С FHS это бьётся точно так же, как и эти симлинки — делаем симлинк /usr→/, и всё по прежнему доступно.