Tolya

Вернее, не VPN, а прокси. Сейчас я использую ssh -D на свой виртуальный сервер в Нидерландах, но поскольку ни по каким протоколам кроме ssh на этот сервер сейчас не попасть, мобильные операторы даже https запросы больше килобайта режут, то он функционирует пока оплачен. А оплата скоро кончится. Платить же за полноценный сервер, который я использую только как точку выхода VPN не хочется.

Требования следующие:

1. Это должна быть не VPN куда заворачивается весь траффик, а место, куда можно перенаправить только некоторые запросы. Запросы к российским сайтам, к моей локальной сети и еще к некоторым сайтам туда попадать не должны. Делаю я это с помощью расширения FoxyProxy, которая имеет набор шаблонов, с которыми сравнивается URL, и в зависимости от выбора направляет запрос на ту или иную прокси (или без прокси непосредственно в интернет).
2. Оно не должно стоить дороже чем хостинг полноценного VPS. Ну или посоветуйте VPS ценой этак доллар или два в месяц, куда можно будет зайти по ssh с ключиком -D и без проблем оплачивать из России. Диска много не нужно, памяти не нужно, нужен доступ по ssh и чтобы провайдер не нервничал по поводу того что входящий траффик равен исходящему.
3. Оно не должно требовать установки какой-нибудь проприетарной фигни на мои компьютеры. Т.е. работать по стандартным протоколам - VMESS , VLESS и ShadowSocks считаются стандартными. 4.Желательно, чтобы его можно было использовать не только из браузера, а из любой программы, которая понимает что такое прокси (или совсем из любой с использованием socksify).

Надо всё-таки в 2025 году отметиться, что я тоже что-то делал с нейронками. Поэтому я сгенерировал обложку к «Технократам и Имперцам»

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

Использовалась нейросеть Qwen

Мне понравилось то что можно рисовать инкрементально. Сначала генерируем пейзаж, потом добавляем туда одного персонажа, потом второго. Лауру, правда, решил уже не впихивать.

Начало диалога было следующим:

USER

Вершина горы, покрытая зарослями голубики. Открывается вид на бескрайние леса. Над лесом огромная грозовая туча.

ASSISTANT

картинка

USER

К предыдущей картинке добавим девушку с длинными темными волосами, в белой тунике, стоящую на вершине горы спиной к нам и протягивающую руки к туче. От рук к туче поднимаются синеватые огни святого Эльма длиной примерно в метр.

ASSISTANT

та картника, колорая приведена выше.

Кажется, авторы RFC 5545 рассчитывали на использование их пользователями GTD.

Иначе зачем бы объекту VTODO статус DELEGATED?

Если у нас набор задач общий для всех членов команды, логичнее иметь поле ASSIGNEE как, скажем, в jira.

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

Авторы todoman похоже, тоже что-тоимели в виду GTD, предусмотрев команду копирование задачи из списка в список. Хотя правильнее было бы не копировать, а перемещать. GTD заточена под бумажные описания задач, которые скопировать сложно, а переместить из лотка в лоток - легко.

И в андроином tasks.org поддержка множественных списков тоже есть. Хотя эта программа больше расчитана на работу с категориями задач. Но категории - это по смыслу тэги. Вещь неструктурировананая, способствующая разведению бардака. Правда в tasks.org есть поддержка подзадач, причем произвольной глубины вложенности. а в todoman нет. Я было подумывал ее туда дописать, но что-то с ходу не получилось. Больно уж там много функиональности унесено в модуль icalendar, который в другом репозитории и в другом пакете. Править их параллельно - неудобно.

Лучше сразу своё делать. Потому что все кто работает с RFC 5545 умеют аккуратно сохранть неподдерживаемые поля. Так что с одним и тем же календарем (список задач как ни странно - часть календаря) можно работать разными программами, причем как локально, так и по сети с помощью CalDAV. Благо есть на свете vdirsyncer

https://www.theregister.com/2025/12/22/europe_gets_serious_about_cutting/

https://tech.slashdot.org/story/25/12/23/1843236/europes-public-institutions-are-quietly-ditching-us-cloud-providers

Тут пишут что европейские правительственные и муниципальные органы слегка задумались о том, что 90% их цифровой инфраструктуры зависит от заокеанских производителей софта и провайдеров облачных сервисов.

Интересно как насчет тайских производителей жестких дисков и тайваньских производителей оперативной памяти? Наладить-то собственное производство сложнее будет, чем перейти с google на nextcloud и с MS Office на LibreOffice.

X-Post to LJ

Случилась тут у меня в VK дискуссия с nataraj по поводу того, могут ли среди современных студентов попасться "опытные пользователи Linux". И что вообще такое "опытный пользователь Linux" из которого должна получиться хорошая заготовка для будущего разработчика прикладных программ.

На мой взгляд, пользователь, это тот кто решает на компьютере какие-то свои задачи, желательно не имеющие отношения к IT (а то будет "это вроде как машина скорой помощи идет, сама режет, сама давит, сама помощь подает"). Причем пользователем Linux в этом контексте является не тот, кто использует Linux-систему в качестве платформы для запуска браузера, используемого для доступа к чужим сайтам, на которых задачи и решаются, а тот, кто использует для решения задач именно средства, специфичные для POSIX-совместимых систем. Шелл, coreutils, в меньшей степени скриптовые языки вроде Perl и Python - те более системно-независимы.

То есть критерием "опытного пользователя Linux" для меня будет в первую очередь отсутствие четкой грани между выполнением команд в интерактивном шелле и написанием скрипта, и легкость перехода через эту грань в любую сторону.

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

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

X-Post to LJ