Вчера разбирались с коллегой, почему у него странно работает ssh на машину с установленным #stal/ix.

Если совсем коротко, то это выглядело так:

# ssh host env
...
A=B
...
# ssh host
> env
...
A=C
...

Ну, то есть, натурально, сильно разный environment при запуске команды в batch режиме ssh, и такой же команды в интерактивном режиме.

Дело свелось вот к этой функции - https://github.com/mkj/dropbear/blob/master/dbutil.c#L371

Совсем коротко - для интерактивного режима оно запукает shell в login mode, и тогда shell читает содержимое /etc/profile, и далее все, как положено, а для запуска batch команды запускает шел в неинтерактивном режиме, через -c. Ну и этот shell, конечно, наследует env от parent process, и не зачитывает на старте /etc/profile.

Я тут не очень понимаю, как правильно (и кто это "правильно" вообще определяет).

Мне лично кажется, что и во втором случае нужно запускать login shell, но не в интерактивном режиме!

Я это у себя зачинил так - https://github.com/pg83/ix/blob/main/pkgs/bin/dropbear/ix.sh#L7 https://github.com/mkj/dropbear/blob/master/dbutil.c#L388 - вот тут заменяем -c на -cl, указывая, что надо зачитать env из /etc/profile.

Вот теперь думаю, надо ли с этим стучаться в dropbear upstream, или меня там сразу нахер пошлют?

Мне кажется, надо бы апнуть этот замечательный пост, в котором я объяснял, зачем я затеял свой дистрибутив Linux.

Если коротко - то меня бесят многие вещи, сделанные в Unix/Linux, и самый простой способ их починить - это иметь контроль над всем окружением!

Вот, если говорить про предыдущий пост, где я написал про "странность" поведения ssh daemon в интерактивном vs. batch режиме.

На самом деле, эта странность очень просто объясняется - она вызвана путаницей между login shell, и interactive shell!

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

Но это в корне неверно!

Login shell, это, если очень грубо, первый shell в цепочке для вашего пользователя. Обычно его стартует какой-нибудь display manager, типа mingetty, agetty, emptty, greetd, sddm, да тысячи их. ssh, putty, telnet, mosh, и так далее - это тоже штука, которая spawn первую shell в цепочке!

Interactive shell - это то, куда вы вбиваете команды с клавиатуры.

Это, конечно, довольно разные штуки.

(Кстати, немного в сторону - если у вас бывают случаи, когда в PATH повторяются одни и те же элементы - это значит, что вы не понимаете разницу между этими сущностями, и у вас иногда два раза срабатывает конструкция добавления чего-то к PATH, потому что лежит не в том файле)

Проблема тут еще усугубляется тем, что разные shell читают разные startup файлы, в зависимости от режима.

Например, bash читает /etc/profile как и в interactive, так и в login mode. А большинство других shell так не делают!

Короче, тут явно видны треш, угар, и содомия, наслоение привычек, непонимания, и так далее. Оцените, например, только /etc/environment - https://superuser.com/questions/664169/what-is-the-difference-between-etc-environment-and-etc-profile - это упячка, родившаяся из того, что иногда надо сделать "login", но без "shell", а переменные откуда-то надо взять!

Поэтому, конечно, я тут намерен сделать все "правильно" (*), а не воспроизвести хак, к которому все привыкли!

Почему?

Потому что, если бы меня устраивал этот хак, я бы поставил Fedora! А мне нужно better!

(*) Правильно - конечно, ssh и прочие должны запускать первый shell в login mode. Еще лучше - для каждого shell пользователь должен разобраться, в какие файлы ему класть interactive настройки (типа completion), а куда - login.

https://xn--r1a.website/PAAMAYIM_NEKUDOTAYIM/30

Не могу не утащить из комментариев!

Продолжается замечательная история про #gil в Питоне.

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

https://discuss.python.org/t/pep-703-making-the-global-interpreter-lock-optional/22606

Я настроен довольно пессимистично, потому что люди прекрасно понимают, что это сильно фрагментирует экосистему. Условно говоря, будешь ты приходить к автору third party модуля с просьбой починить в нем баг в многопотоке(или починить регрессию в однопотоке), а он будет посылать нахер, с "не использовали многопоток, и неча начинать". В итоге, все разделится по признаку "можно в многопоток/нельзя", и это не очень.

https://www.opennet.ru/opennews/art.shtml?num=58472

Пишут, что в Chromium можно в Rust.

Новость, конечно, не очень приятная!

Я люблю, когда на Rust переписывают какую-то кодину на C, но вот сочетание Rust + C++ мне не очень ОК. Потому что С++ достаточно безопасен, настолько, что проблемы от взаимодействия 2 языков перевешивают профит. Про такую попытку Гугла использовать Rust в С++ кодовой базе я уже писал - #cras.

"Для упрощения интеграции кода на Rust с существующим кодом на C++ и обхода связанных с интеграцией рисков и ограничений, в настоящее время решено ограничиться однонаправленным взаимодействием - обращением из С++ к Rust (т.е. код на Rust может лишь вызываться из кода C++ через функции API, но не смешиваться с кодом на C++), что также даст возможность держать под контролем дерево зависимостей. Вторым ограничением является поддержка только сторонних библиотек, поставляемых в форме отдельных компонентов, не привязанных к Chromium и имеющих API, ориентированный на выполнение конкретных задач"

Пока мне кажется, что это такой эксперимент, и что эти правила позволяют затащить какой-то кодек на Rust, или вот librsvg. Вполне возможно, что этим все и ограничится, как двумя файликами "для галочки" в #cras.

И еще такой вопрос - а что с #carbon?

Кажется, что Rust тут пытается откушать как раз нишу #carbon, и это довольно странно. Carbon все?

https://www.opennet.ru/opennews/art.shtml?num=58465 #sfc

Слуште, я, когда прочитал текст этой новости, полез в календарь, и проверил, какое сегодня число. Но потом увидел, что, в списке подписантов, есть известные левые упыри под названием #sfc, и все встало на свои места.

Интересно, много ли народу съехало с github, после их прошлой инициативы?

Такие IT новости нам по душе! Хотя я бы, конечно, ожидал бы такого от blizzard!

Давненько не было новостей про #toybox! #busybox

Вышла новая версия, полез посмотреть, каких новых команд они досыпали.

https://github.com/landley/toybox/blob/master/toys/pending/git.c

Пожалуйста, вот вам git client за 600 строк кода!

Никакого продуктового смысла в этом, конечно, нет, но так-то довольно интересно поштырить, чтобы понять, что ядро git - это вот эти вот 600 строк кода, с кучей слоев вокруг.

Есть такой классный torrent клиент transmission.

Мне казалось, что на него, в последние годы, подзабили - последний релиз был почти 3 года назад, а до этого - в 18 году.

Но нет, коллеги продолжают работать, и за последние несколько месяцев вышло 3 беты, думаю, скоро релиз!

https://github.com/transmission/transmission/releases/tag/4.0.0-beta.3

Самое IMHO вкусное - это порт на QT6.

Не могу не похвастаться. #cross

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

С самого начала разработки #ix, я закладывал в него такую возможность - учет host/target в графе, возможность указывать библиотеки, нужные для сборки, в разных контекстах (host/target), прокидывание этой информации до cmake/meson/autohell, до каждого запуска clang/lld, и так далее.

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

Понятно же, что, когда тулчейн нужно собрать под host, а библиотеку этим тулчейном уже под host+LTO, это уже тоже кросс-компиляция?

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

И, вот, пожалуйста!

pg-> ./ix build lib/c++/15 --target=linux-aarch64 
READY /ix/store/eS3L7CZ3qS6dEkaX-rlm-ephemeral/touch
pg-> find /ix/store/...-rlm-ephemeral/lib/
/ix/store/...-rlm-ephemeral/lib/
/ix/store/...-rlm-ephemeral/lib/Scrt1.o
/ix/store/...-rlm-ephemeral/lib/crti.o
/ix/store/...-rlm-ephemeral/lib/crtn.o
/ix/store/...-rlm-ephemeral/lib/crt1.o
/ix/store/...-rlm-ephemeral/lib/rcrt1.o
/ix/store/...-rlm-ephemeral/lib/libm.a
/ix/store/...-rlm-ephemeral/lib/librt.a
/ix/store/...-rlm-ephemeral/lib/libpthread.a
/ix/store/...-rlm-ephemeral/lib/libcrypt.a
/ix/store/...-rlm-ephemeral/lib/libutil.a
/ix/store/...-rlm-ephemeral/lib/libxnet.a
/ix/store/...-rlm-ephemeral/lib/libresolv.a
/ix/store/...-rlm-ephemeral/lib/libdl.a
/ix/store/...-rlm-ephemeral/lib/libcrt.a
/ix/store/...-rlm-ephemeral/lib/libc.a
/ix/store/...-rlm-ephemeral/lib/libc++abi.a
/ix/store/...-rlm-ephemeral/lib/libc++.a
/ix/store/...-rlm-ephemeral/lib/libc++unwind.a
pg-> llvm-objdump --disassemble 
    /ix/store/...-rlm-ephemeral/lib/crtn.o

crtn.o:  file format elf64-littleaarch64

Disassembly of section .init:

0000000000000000 <$x.0>:
       0: a8c17bfd       ldp  x29, x30, [sp], #16
       4: d65f03c0       ret

Disassembly of section .fini:

0000000000000000 <$x.1>:
       0: a8c17bfd       ldp  x29, x30, [sp], #16
       4: d65f03c0       ret
pg->

Понятно, что пока так собираются только самые базовые вещи, придется зачинивать кучу таргетов, которые, в процессе работы, строят и запускают host тулзы, но не умеют сами в кросс-компиляцию, но начало положено!

Забавно, что от "собрать пару либ" до "собрать содержательный пакет" - всего пара строк кода! #cross

pg-> ./ix build bin/sed --target=linux-aarch64
READY /ix/store/...-rlm-ephemeral/touch
pg-> /ix/store/...-bin-sed/bin/sed 
bash: /ix/store/...-bin-sed/bin/sed: 
    cannot execute binary file: 
    Exec format error
pg-> 

https://github.com/pg83/ix/commit/c9a76659a00c2b94974eb2c9edd67843cd85663a

Битва людей против машин продолжается.

На Stable Diffusion подали в суд. В иске утверждается, что нейросети нарушают авторские права миллионов художников. Заявляется, что права нарушаются уже на стадии обучения нейросетей. Нейросети называют «инструментами для создания коллажей 21 века».

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

По дороге досталось Midjourney и Devian Art.

Истцы требуют возмещение ущерба (сумму предложили определить суду). Stable Diffusion обвиняют в незаконном обогащении. К иску предложили присоединиться художникам, которые недовольны генераторами изображений.
https://stablediffusionlitigation.com/
На реддите приподвскипает:
https://www.reddit.com/r/MachineLearning/comments/10bkjdk/n_classaction_lawsuit_filed_against_stability_ai/