> Вспомнил. Я его смотрел, но как-то не вкурил его философию. Выглядит круто, возможности прикольные, но пользоваться им я так и не научился.
Там фишка в том, что есть демон, который реализует сам WM, и клиент к нему. И весь конфиг клиентом делается.
Это позволяет писать конфиг на любом языке.

>> Вспомнил. Я его смотрел, но как-то не вкурил его философию. Выглядит круто, возможности прикольные, но пользоваться им я так и не научился.
Difrex> Там фишка в том, что есть демон, который реализует сам WM, и клиент к нему. И весь конфиг клиентом делается.
Difrex> Это позволяет писать конфиг на любом языке.

Примерно как в bspwm, видимо. Есть bspwm и есть bspwmc. Конфиг на чём угодно, что умеет в шелл-вызовы. Для управления исключительно bspwmc юзается. Вкупе с sxhkd очень вкусно получается.

+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.

>Drone CI тянет за собой Docker и, насколько понимаю, запускает его на каждый чих, при каждой сборке. Это оттолкнуло сразу
Почему оттолкнуло? У тебя получаются изолированные повторяемые билды каждый запуск.
GitlabCI тоже все в докере(dind) собирает.

>В идеале, конечно, хотелось бы что-нибудь подобного с синтаксисом вроде Ansible playbook, но чтобы многие вещи для сборки и развёртки были автоматизированы и был удобный гуй на всякий случай.
Посмотри на CircleCI - там LISP(Clojure) :)

А вообще, если ты хочешь опенсорс собирать, то бери TravisCI и не парься со своими серваками.

>>Drone CI тянет за собой Docker и, насколько понимаю, запускает его на каждый чих, при каждой сборке. Это оттолкнуло сразу
Difrex> Почему оттолкнуло? У тебя получаются изолированные повторяемые билды каждый запуск.

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

Difrex> Посмотри на CircleCI - там LISP(Clojure) :)
Difrex> А вообще, если ты хочешь опенсорс собирать, то бери TravisCI и не парься со своими серваками.

CircleCI и Travis не подходят по причине того, что это Software as a Service. Да, это удобно, быстро, прикольно, но надо всегда иметь способы быть независимыми от чужого дяди.

В конечном итоге придётся, видимо, осваивать докерные штучки вроде DroneCI и GitlabCI, а пока что я делаю тупо всё на баш-скриптах и не заморачиваюсь.

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

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

> Да и как-то ради простенького сборочного процесса сохранять отдельный контейнер жирновато.
Сохраняй полученный артифакт, а не новый образ.

Продолжаю учиться писать программы на питоне и возник один странный, может быть, вопрос. Есть строка, в которой хранится в "сыром" виде выхлопом x/c. То есть данные в виде

echo.area:messages_count

Я её хочу обработать минимальным количеством кода. Так что решил использовать генератор:

{x.split(":")[0]: x.split(":")[1] for x in x_i.split("\n") if ":" in x}

Но при этом мне очень не нравится дважды вызванный .split(":"). Можно как-то произвести сплит единожды для каждой итерации или придётся городить огород для этого?

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

AL> Продолжаю учиться писать программы на питоне и возник один странный, может быть, вопрос. Есть строка, в которой хранится в "сыром" виде выхлопом x/c. То есть данные в виде
AL> ====
AL> echo.area:messages_count
AL> ====
AL> Я её хочу обработать минимальным количеством кода. Так что решил использовать генератор:
AL> ====
AL> {x.split(":")[0]: x.split(":")[1] for x in x_i.split("\n") if ":" in x}
AL> ====
AL> Но при этом мне очень не нравится дважды вызванный .split(":"). Можно как-то произвести сплит единожды для каждой итерации или придётся городить огород для этого?

Благодаря товарищам из Instead группы в ТГ решил это следующим образом:

{y[0]: int(y[1]) for y in (x.split(":") for x in counts.split("\n") if ":" in x)}

Если предложите вариант проще и быстрее, то буду рад.

> Я её хочу обработать минимальным количеством кода
В тему, что меня бесит -- это питоновые однострочники. Оно работает не быстрее, чем если ты запишешь это в несколько строк,
а вот читаемость падает.

>> Я её хочу обработать минимальным количеством кода
Difrex> В тему, что меня бесит -- это питоновые однострочники. Оно работает не быстрее, чем если ты запишешь это в несколько строк,
Difrex> а вот читаемость падает.

А мне наоборот компактность кажется читаемее. По крайней мере в генераторах. К тому же зачастую генератор получается быстрее циклического создания списка или словаря, вроде. Но это вкусовщина, конечно.

>> Я её хочу обработать минимальным количеством кода
Difrex> В тему, что меня бесит -- это питоновые однострочники. Оно работает не быстрее, чем если ты запишешь это в несколько строк,
Difrex> а вот читаемость падает.

Кстати, в итоге сделал вот так вообще. Даёт небольшой прирост в скорости и по идее легче читается.

d = {}
for (key, vaule) in re.findall("(.+):(.+)\n", counts):
    d[key] = value

Кстати, насколько я понял, регулярки в re ложатся в философию питона как родные и всегда есть возможность получить или список или итератор. Или баловаться со смещением в цикле, что навряд ли будет быстро.

Я правильно думаю, что нет простого способа просто следующее совпадение извлечь?

> Я правильно думаю, что нет простого способа просто следующее совпадение извлечь?
Ага, нету.

Скомпиль, кстати, регулярку сначала, будет еще быстрее

r = re.compile("(.+):(.+)\n")

>> Я правильно думаю, что нет простого способа просто следующее совпадение извлечь?
Difrex> Ага, нету.

Понятно. И даже ожидаемо, так как оно немного противоречит философии питона, насколько я её понимаю =)

Difrex> Скомпиль, кстати, регулярку сначала, будет еще быстрее
Difrex> ====
Difrex> r = re.compile("(.+):(.+)\n")
Difrex> ====

Как раз поигрался вчера с этим немного и собирался в ближайшее время коммитнуть это изменение. Спасибо.

Случайно наткнулся на это чудо (Папа может в СИ): https://m.youtube.com/watch?v=cdX8r3ZSzN4

А искал, на самом деле, вот это (Write in C): https://www.youtube.com/watch?v=XHosLhPEN3k

Но вторая -- давно известная шутка. А вот "ПАПА МОЖЕТ СИ" первый раз услышал. :)

Peter> Но вторая -- давно известная шутка. А вот "ПАПА МОЖЕТ СИ" первый раз услышал. :)

Это широко известная группа Научно-Технический Рэп. Их самые хитовые песни - это "Делай бэкап", "Тыжпрограммист", "Дедлайн", "Курим мануал"

А вот по их песням про математику (да, такие у них тоже есть) я на первом курсе заучивал теоремы. Очень креативные тексты и "качающая" музыка.

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

vit01, btimofeev
Подскажите товарищи, накидайте годной маны, как быстро без регистрации и смс, собрать простую приложуху под сабжевую систему на смартвоне любом, умеющую одной кнопкой --пересобирать мир--, запускать стрим потока в строенный в приложуху радиво плеер?!

Тебе нужно приложение для проигрывания одной интернет-радиостанции?

Можешь посмотреть исходники приложения Transistor https://github.com/y20k/transistor, оно довольно простое.

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

Ну и вообще, как бы другие советы, на чем/под чем и как лучше, удобнее, современнее собирать apk?!

jmaks> Ну и вообще, как бы другие советы, на чем/под чем и как лучше, удобнее, современнее собирать apk?!

Проще всего поставить Android Studio https://developer.android.com/studio Программы пишутся на Java/Kotlin/C/C++

Ну а дальше можно начать с изучения документации https://developer.android.com/guide/ или startandroid.ru

Ещё в последнее время становится популярным фреймворк Flutter https://flutter.dev/ Он позволяет писать нативные приложения сразу и для Android и для iOS и для веба. Здесь программы уже пишут на языке Dart. Правда и АПК с хелло ворлдом будет иметь размер мегабайт 10.

jmaks> vit01, btimofeev
jmaks> Подскажите товарищи, накидайте годной маны, как быстро без регистрации и смс, собрать простую приложуху под сабжевую систему на смартвоне любом, умеющую одной кнопкой --пересобирать мир--, запускать стрим потока в строенный в приложуху радиво плеер?!

btimofeev уже всё объяснил, достаточно лишь разгрести исходники парочки приложений-плееров на F-Droid

jmaks> Ну и вообще, как бы другие советы, на чем/под чем и как лучше, удобнее, современнее собирать apk?!

От себя добавлю, что нынче Qt очень подтянулись в поддержке андроида. Если уже знаешь Qt и умеешь на нём писать, то начать и поддерживать приложение будет нетрудно.

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

Anotheroneuser>> Не найдётся у кого-нибудь muttrc для mail.yandex? Или ссылки на нормальное руководство.
AL> Ну так mutt это только читалка. Unix-way же. Гуглиться надо, например, про связку mutt + fetchmail + procmail + msmtp.
AL> Mutt для чтения и написания писем, fetchmail скачивает почту с сервера, procmail сортирует её, msmtp отправляет почту.
AL> Если не забуду, тр вечером посмотрю у себя. Где-то должны были остаться конфиги для этого добра.

Лучше написать таки своё; и сабж разберёшь, да и свои таки сделаешь настройки.

https://syslogblog.blogspot.com/2008/10/mutt-fetchmail-exim4-smarthost-debian.html
Вот кстати, одна из статеек в этих ваших интернетах; её таки писал сам gl00my aka Peter.

А так да, ничего не поменялось принципиально за много лет.
Вот тут можно поискать настройки и примеры mutt и прочих, линуксформат крутой был журнал. R.I.P.
Press 'F' просто... Эх, грусть...
http://wiki.linuxformat.ru/

У димы можно посмотреть базисные штуки, дефолтные конфиги, довольно много всяких гайдов напилено...
https://www.dmosk.ru/miniinstruktions.php?mini=mutt

На линуксцентре тож, что-то годное помню почерпнул для себя
http://www.linuxcenter.ru/lib/articles/networking/linuxmail.phtml

Так же как и на опеннете
https://www.opennet.ru/docs/RUS/mutt4users/

+++ Caesium/0.4 RC1

Что бы там не говорили злопыхатели, golang прекрасен! Пока делал ноду, полюбил его ещё больше. Конечно, пока пишу совсем не "идеоматичный" код, но начал постепенно его чувствовать.

Лично для меня это что-то вроде "Си" на стероидах. Что-то между низким уровнем (с его простотой) и современными более абстрактными языками. Идеален для написания бекендов!

А его кросскомпиляция? Наконец-то я избавился от вороха зависимостей, dependency hellов и избежал унылой участи запускать всё в контейнерах. И всё это благодаря go!

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

Короче, Роб Пайк рулит! Спасибо за наше счастливое детство!

hugeping> Что бы там не говорили злопыхатели, golang прекрасен! Пока делал ноду, полюбил его ещё больше. Конечно, пока пишу совсем не "идеоматичный" код, но начал постепенно его чувствовать.
hugeping> Лично для меня это что-то вроде "Си" на стероидах. Что-то между низким уровнем (с его простотой) и современными более абстрактными языками. Идеален для написания бекендов!
hugeping> А его кросскомпиляция? Наконец-то я избавился от вороха зависимостей, dependency hellов и избежал унылой участи запускать всё в контейнерах. И всё это благодаря go!
hugeping> Помню, когда читал книжку, чуть не плакал. Везде сквозил дух старого доброго Си, но только переосмысленный.
hugeping> Короче, Роб Пайк рулит! Спасибо за наше счастливое детство!

Когда пробовал go испытал примерно те же чувства. Пайк и Томпсон всё таки молодцы и понимают в языках :)

Вы его так рекламируете. Что хочется прям почитать про этот ваш Го.
Хотя после си, перла, пхп, питона и "богомерзкого" JSа в голове и так полная каша. :(
Жаль мозги прокачать не получается.

> Вы его так рекламируете. Что хочется прям почитать про этот ваш Го.

Если нравится Си, то понравится и Go. Хотя я был уже подготовлен Питоном и Lua, но всё-равно, думаю, понравится.

Изучаю, время от времени, консоли из этого списка: https://github.com/paladin-t/fantasy

Приглядываюсь, прицениваюсь, так сказать. Тики, Пики, Лики... Хочется низкоуровневой 8-битной экзотики на асме или чтобы вообще без кода. Думал уже ничего не может быть проще Битси. Оказалось, может.

PIX64. Это такой no-code в "пейнте". А может и не в "пейнте". Ну, то есть, берем мышку, создаем 64x64 png, и оно как-то там само все движется...

Осталось только найти для него удобный редактор. А в идеале - конвертер, чтобы из npp прямо в png, типа как xmp (кстати, кроме гимпа, кто-нибудь может работать с этим форматом?)

А вы себе что присмотрели?

Я когда-то интересовался одной из первых подобных платформ, разработанной еще в 70-х годах - CHIP-8. Там всего два цвета на экране, разрешение 64х32, 16 кнопок клавиатуры, из звуков только "Бииип" и игры пишутся на ассемблере. Но игры конечно простенькие - пинг-понг, арканоиды и подобное. Я учился азам написания эмуляторов на этой системе - вот тут мой эмулятор лежит https://github.com/btimofeev/emuchip

Если мне захочется "живого" железа, я скорее всего выберу спектрум. В детстве я программировал на БК0010-01, а вокруг были спектрумы. Поэтому, интересно. :) Даже читал книгу по железу спека не так давно. Но реально, не уверен что руки дойдут. Много всего. :) Сейчас вот Plan-9 увлёкся.

А в плане виртуальных консолей, PICO8 для меня лучшая. В ней есть баланс ограничений, которые (на практике проверил) идеально для меня подходят. Жаль, что закрытая только. Но хотя бы формат игр открыт и есть открытые плееры...

> Я когда-то интересовался одной из первых подобных платформ, разработанной еще в 70-х годах - CHIP-8. Там всего два цвета на экране, разрешение 64х32, 16 кнопок клавиатуры, из звуков только "Бииип" и игры пишутся на ассемблере. Но игры конечно простенькие - пинг-понг, арканоиды и подобное. Я учился азам написания эмуляторов на этой системе - вот тут мой эмулятор лежит https://github.com/btimofeev/emuchip

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

У меня когда-то был Микроша, но получалось запускать на нем только бейсик, да ещё какой-то текстовый редактор. Там и ассемблер был, но для меня тогда это было что-то инопланетное.

johnbrown> Там, какой-то высокоуровневый ассембер, как я понял, используется, надеюсь будет полегче. Давно хотел приобщиться. Вчера читал руководство по нему, про звуки ничего не нашёл, думал не поддерживает вообще. Ну, здорово, что консоль реально существовала, не фэнтези )

Она реально не существовала. Chip-8 больше похож на Java или современные виртуальные консоли, это была типа виртуальная машина которая проигрывала игры написанные на этом простеньким ассемблере. А распространялось это на несколько разных компьютеров тех лет.

Ассемблер там простой, я писал небольшую статью с примерами и разбором кода как выводить изображения и обрабатывать события клавиатуры, если интересно можешь почитать https://emunix.org/post/writing-chip-8-emulator-part-3/

Не вижу смысла в новой эхе. Но, на пример, динамик фетчит все из list.txt. Так что новая эха у меня на ноде появится.

ЗЫ: хочу тянуть по 9000 сообщений

Difrex> Не вижу смысла в новой эхе. Но, на пример, динамик фетчит все из list.txt. Так что новая эха у меня на ноде появится.

Движение ради движения же.

Difrex> ЗЫ: хочу тянуть по 9000 сообщений

Для этого нам нужно начинать пользоваться технологией :)

+++ Caesium/0.4 RC1

нифига не понял, почему это в develop, но утянул себе develop тоже :)

Долго искал таковое решение, но не нашёл вообще. А именно: хотелось бы иметь файл или кучку файлов в одном календарном просто текстовом формате, которые будут распознаваться и просматриваться соответствующим календарным софтом и на linux, и на android.

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

Существует ли такое решение у кого-нибудь?

---
Из найденного самое ближайшее это использование calcurse - https://github.com/avidseeker/awesome-syncthing#icsx5 . Однако это работает только в одну сторону...

tuple> Долго искал таковое решение, но не нашёл вообще. А именно: хотелось бы иметь файл или кучку файлов в одном календарном просто текстовом формате, которые будут распознаваться и просматриваться соответствующим календарным софтом и на linux, и на android.
tuple> А ещё хотелось бы, чтобы можно было не только просматривать через интерфейс приложений, но и редактировать события, а также уведомления, основанные на времени события... Но это так - мечты.

Кхм... Я сейчас как сектант скажу, но Emacs и его Org-mode выглядит как то, что тебе нужно. И даже существенно больше.

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

Как бороться с сабжем в легаси-коде? Попадаются прямо такие вещи, что я проямо колдобюсь, когда сталкиваюсь.

Последнее из прекрасного, мьютекс со счётчиком локов, который нигде не используется.

Я ещё могу нафантазировать зачем нужен счётчик ReadLock'ов в RWMutex, но вот в самом обычном мьютексе это нафига? Причём реально по всему проекту этот счётчик не используется нигде.

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

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

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

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

> Кхм... Я сейчас как сектант скажу, но Emacs и его Org-mode выглядит как то, что тебе нужно. И даже существенно больше.

Я из другой секты - vim. Emacs немного трогал, но не хочу в него погружатся, а то придётся пересматривать парадигмы повседневной работы за компом. Хотелось бы некое независимое от выбранного редактора решение.

О - а я из третьей секты :)
Точнее из тех нормальных людей, кто вырос на MS-DOS ;)
Я с конца 90х все свои программы пишу в mcedit (mc это клон нортон коммандера для линуха), хотя в 1996-1997 немного посидел в редакторе joe, так как у него комбинации клавиш повторяли борландовские (aka WordStar shortcuts)…

> Как бороться с сабжем в легаси-коде?

Бороться надо на этапе разработки - надо становиться техлидом и пинать разрабов чтобы они не вылезали за рамки техзадания - многие молодые разработчики (особенно российские) норовят на любую тривиальную задачу нагородить «сферического коня в вакууме» - суперуниверсальное решение, которое не только поставленную задачу решает, но и любые другие сходные с ней или которые могут возникнуть на базе текущей задачи в ближайшую сотню лет - в итоге получается овердохера кода который может поддерживать только первоначальный автор, тем самым обеспечивая себе «job security»…

Родился после 2000-го года, не застал того времени. Году в 19-ом попался мне на глаза Luke Smith вот закрутилось и завертелось у меня с vim'ом.

tuple> Я из другой секты - vim. Emacs немного трогал, но не хочу в него погружатся

Да ты не переживай, там надо только c org-mode разобраться (почитай доку - это реально очень крутой органайзер https://orgmode.org/ ).
Я тоже когда-то vim использовал (да и сейчас везде где можно стрелки на hjkl), но после знакомства с org-mode больше начал пользоваться емаксом.
P.S. Edited: 2024-09-27 21:00:50

>> Кхм... Я сейчас как сектант скажу, но Emacs и его Org-mode выглядит как то, что тебе нужно. И даже существенно больше.
tuple> Я из другой секты - vim. Emacs немного трогал, но не хочу в него погружатся, а то придётся пересматривать парадигмы повседневной работы за компом. Хотелось бы некое независимое от выбранного редактора решение.

Это PlainText. Просто есть встроенный софт, который делает всё, что тебе нужно.

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

>> Как бороться с сабжем в легаси-коде?
shaos> Бороться надо на этапе разработки

У меня нет машины времени, чтобы вернуться на шесть лет назад.

shaos> надо становиться техлидом и пинать разрабов чтобы они не вылезали за рамки техзадания

Обычно так и пишем. Но в старом коде море говнокода.

shaos> многие молодые разработчики (особенно российские) норовят на любую тривиальную задачу нагородить «сферического коня в вакууме» - суперуниверсальное решение, которое не только поставленную задачу решает, но и любые другие сходные с ней или которые могут возникнуть на базе текущей задачи в ближайшую сотню лет - в итоге получается овердохера кода который может поддерживать только первоначальный автор, тем самым обеспечивая себе «job security»…

Универсальность это хорошо. Только не ценой сложного и запутанного кода. Есть же, в конце концов, паттерны под это.

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

shaos> О - а я из третьей секты :)
shaos> Точнее из тех нормальных людей, кто вырос на MS-DOS ;)

Тогда я предпочитал борландовские IDE. Но, как позже оказалось, есть более интересные и совершенные решения.

shaos> Я с конца 90х все свои программы пишу в mcedit (mc это клон нортон коммандера для линуха), хотя в 1996-1997 немного посидел в редакторе joe, так как у него комбинации клавиш повторяли борландовские (aka WordStar shortcuts)…

Mcedit уже даже для конфигов перестал использовать. Быстрее в vim поправить конфиг :)

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

tuple>> Я из другой секты - vim. Emacs немного трогал, но не хочу в него погружатся
btimofeev> Да ты не переживай, там надо только c org-mode разобраться (почитай доку - это реально очень крутой органайзер https://orgmode.org/ ).

Именно org-mode стал для меня первым шагом в переходе с vim на emacs. Хотя, для мелких вещей и по ssh до сих пор предпочитаю vim.

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

Скажем так: у меня "стэк" системы заметок не позволяет перейти на org-mode легко. Веду нечто вроде vimwiki (+одноимённый плагин), стараясь следовать методу Zettelkasten. И это всё дело сидит в markdown, от которого уходить не хотелось бы.

Конкретно сейчас список дел лежит в виде todo.txt (https://github.com/todotxt/todo.txt). А вот хотелось бы найти формат похожий, но для календарных событий.

Есть calendar.txt, однако он не имеет никакой поддержки - никому неизвестен.
Есть утилита remind (https://wiki.archlinux.org/title/Remind), но достаточно устарела, неудобна с русским языком.

tuple> Скажем так: у меня "стэк" системы заметок не позволяет перейти на org-mode легко. Веду нечто вроде vimwiki (+одноимённый плагин), стараясь следовать методу Zettelkasten. И это всё дело сидит в markdown, от которого уходить не хотелось бы.

Ну ой тогда :)

tuple> Конкретно сейчас список дел лежит в виде todo.txt (https://github.com/todotxt/todo.txt). А вот хотелось бы найти формат похожий, но для календарных событий.

Звучит как часок не перле.

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

> У меня нет машины времени, чтобы вернуться на шесть лет назад.

Ну ой тогда :)

Если старый код работает, то не трогайте, а если глючит или тормозит, то аллоцируйте бюджет на "technical debt"...

В теории можно сделать упрощённую и переосмысленную версию того, что я описал в начальном сообщении темы. Написать аналог atq.service (который для юниксовой утилиты at), который будет вызывать notify-send с нужными аргументами на основе текстового файлика, синхронизирующегося между устройствами.

Однако возникает проблема с мобильными устройствами. Гуглы закрутили гайки, и отправка уведомлений, и работа в фоне без костылей невозможна. Тот же Telegram FOSS из F-Droid для того, чтобы быть в фоне постоянно, вынужден держать постоянное неубираемое уведомление.

Ещё есть вариант использовать телеграм для уведомлений на мобильных устройствах, можно даже полностью сделать напоминалку исключительно на телеграме - только взаимодействие с ботом без необходимости писать atq. Минусы? Сливать свои данные в телеграм - не лучшая идея, хоть там уже крутиться куча всего. Ну и не unixway'но.

tuple> для того, чтобы быть в фоне постоянно, вынужден держать постоянное неубираемое уведомление.

Это же прекрасно. Теперь все подряд приложения не запускают свои бесконечные фоновые сервисы и не сажают этим батарейку.

> Это же прекрасно. Теперь все подряд приложения не запускают свои бесконечные фоновые сервисы и не сажают этим батарейку.

В моём случае это работает плохо, так как даже не смотря на постоянное уведомление, telegram куда-то испаряется...