А вот пара картинок к «Императрице Кэт»

Кэт и Кеалор сразу после знакомства на дороге. © kandinsky

Ирра и Джив Маррес © Qwen. Джив у китайской нейросети получился китайцем. Ну ладно, у меня нигде не написано, какие именно расы обитают на Ачжантейе. А от Кандинского мне добиться правильной кошки не удалось.

Хельмутский боевой маникюр © Qwen

Попробовал сгенерировать картинку с той же сценой, что и вчера с помощью Кандинского. То что получилось, Ирине понравилось больше, чем вчерашние варианты от Qwen.

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

Потом попробовал сделать обложку для "Из пешек в королевы". Увы, ничего хорошего не вышло ни из сцены в Утраченном Храме (нарисовать статую Чорсал Кандинский так и не смог), ни из сцены в Айоле. Почему-то оно изобразило Сандру узбечкой (хотя она наполовину татарка, а наполовину вообще англосакс), а дедушку Парвуза - не горным пастухом в папахе и бурке, как было написано в промпте, а каким-то арабом в бурнусе. А главное кот. Хотя был потребован кот ростом в холке до бедра Сандры, был нарисован обычный маленький серо-поласатый кот. При попытке уточнить, что кот должен быть размером с леопарда, оно почему-то заменило на леопарда (причем размером с хорошего тигра) Сандру, а исходного кота - никуда не дело.

Впрочем Qwen со сценой в Утраченном Храме тоже не справилась. Ну никак не удавалось объяснить что свет на статую падает от фонаря в руке Сандры, а не сверху.

Надо всё-таки в 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