Представилась такая альтернативка:

Темучин погиб в детстве или ранней молодости. В результате отсутствия сильной личности, способной объединить монголов, монгольские нойоны передрались, и растратили свою пассионарность впустую, не завоевав ни Китая, ни Средней Азии, ни, тем более Руси.

В результате

1. В середине XIII века в Китае начинается промышленная революция. (согласно Клайву Понтингу китайцы чуть-чуть не успели до монгольского нашествия)
2. На ближнем востоке продолжаются разборки между огузами, сельджуками и кара-киданями. Где-то до начала XV века когда приходят Тимур и Осман. Эти, или их близкие аналоги - никуда не денутся. Но история Ирана может пойти каким-то интересным путем
3. Киев не разграблен Батыем.
4. Скорее всего объединения русских земель вокруг Москвы не происходит. Но экспансия в Дикое поле начинается намного раньше. Поскольку без монголов тамошние кочевые народы уже в XIV веке русским не противник. Поэтому крымское ханство, живущее работогровлей и вассальное Блистательной Порте не возникнет. К моменту возникновения Порты там будет Тьмутараканское княжество, активно торгующее с Генуей и Венецией продукцией полей Северной Таврии.
5. Где-то в конце XIII века на Русь и в Европу начинают проникать китайские промышленные товары. Есть непродолжительный прериод когда у степных кочевников качественные ружья уже есть. а у русских еще нет. Но пушнину в Китае тоже любят. Поэтому довольно быстро наладится торговля и с таежэными жителями.
6. Китайская океаническая экспансия начала XV века не будет остановлена. Бурно растущей промышленности Китая будут нужны рынки и природные ресурсы сначала Индокитая и Индонезии, а потом и всего побережья индийского океана. А Чжан Хэ поплывет к Мадагаскару на судах, оборудованных паровыми машинами и казнозарядной нарезной артиллерией.
7. Барлоломеу Диаш встретится в районе мыса Доброй Надежды с китайской патрульной паровой джонкой, превосходящей его каравеллу по длине в три раза, а по водоизмещению - на порядок.
8. Примерно с момента падения Константинополя начнутся прямые рейсы китайских судов из Китая и Индии в Европу.
9. Реконкиста скорее всего будет происходить медленнее.
10. Высадка китайцев в Мексике и Перу это скорее всего XIV век. Раньше, чем Мадагаскар.

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

Крупным планом

Upd: Один аутригер все же прогрызли:

Cапгрейдил первую железку (основной рабочий ноутбук, Хару) на Debian 13. Которому до выхода еще месяца полтора, есле не два.

Раньше я как-то всегда начинал рабочие машинки апгрейдить за несколько месяцев до выхода. Это bookworm вышел внезапно в июне, а не в августе, и я тогда все апгрейдил после выхода.

А сейчас вот мне приспичило чтобы у меня libssl-dev был версии 3.5.0, а не 3.0.16. Можно было бы конечно отдельную openssl собрать для экспериментов. Но пока проще так.

Первое что обнаружил - поторопились они там переходить на GIMP 3.0. ох, поторопились. Потому что пакет sane (который в исходниках sane-frontends) и xsane еще не готовы к новому интерфейсу плагинов. Похоже что их никто толком не мейнейнет, в результате чего sane (содержащий xsanimage, scanadf и xcam) из дистрибутива вообще выпал в ходе стабилизации, а xsane как был 0.999 так и остался, даже в sid, хотя для gimp3 нужен 1.0 (который еще не вышел. Но коммиты с поддержкй 3.0 там уже в мастер влиты). Пришлось скачать маленький (103 строки) питоновский скрипт xsanecli.py.

Надо еще разобраться, что они там намутили с перездом от FreeRDP2 к FreeRDP3. Не то чтобы мне был сейчас так уж нужен RDP-клиент. Рабочих виндовых виртуалок куда нужно ходить по RDP у меня сейчас нет. Но там интересные вещи вроде proxy и раздачи своей существующей сессии по протоколу rdp.

Ну и еще выпал из дистрибутива utox. Не больно-то и хотелось. Не прижился он у меня. Можно, конечно, qtox поставить.

Тут некоторое время назад обнаружились проблем с работой матричных клиентов. Причем всех. Ну как минимум nheko и fluffychat страдали.

Выяснилось что почему-то перестали работать клиентские соединения на 8448 порт. На 443 все работает и после перенастройки клиентов все стало летать.

При этом synapse продолжает слушать на этом порту и openssl s_client к нему вполне коннектится.

Вопрос в том, а должно ли работать в таком режиме s2s. Ау. nataraj, может потестируем?

Синапс вроде не обновлялся. Сейчас packages.debian.org его вообще ни в bookworm-backports, ни в trixie не показывает. Как выйдет trixie, придется, наверное из sid ставить.

У меня, конечно сразу возникло предположение что это злобный мегафон стал резать https-соединения на нестандартные порты. Если так, то s2s в безопасности - серверов никто в мобильном интернете не держит.

Нашел вот в дистрибутиве пакет libpam-ssh-agent-auth и вот теперь думаю, а повысится ли безопасность моего сервера, если я его буду использовать.

Работает эта штука так - прописывается в /etc/pam.d/sudo и аутентифицирует пользователя желающего сделать sudo, если у него имеется работающий (отфорварженный) ssh_agent с доверенными ключами.

Какому файлу доверять - прописываается в /etc/pam.d/sudo. Можно прописать свой рабочий ~/.ssh/authorized_keys, можно для желающих пользоваться sudo завести отдельный файлик где-нибудь в /etc/.

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

Но главное вообще-то не в этом. Главное в том, что если у нас sudo с паролем, то вообще говоря оно уязывимо к установке keylogger, а вот ssh-вый агент использует криптографию с открытыми ключами, и поэтому не боится перехвата чего либо на стороне сервера.

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

Хотя вот на работе жил я с NOPASSWD в sudoers (там было слишком много серверов и контейнеров, чтобы везде пароли расставлять) и ничего.

P.S. Соберетесь настраивать у себя, не забудьте прописать в /etc/sudoers, что environment кирпичом не чистят переменную SSH_AUTH_SOCK из environment удалять не надо. А то не найдет вашего агента.

X-Post to LJ