Apple: Мы уберём жест из рекламы что бы не ущемлять корейцев

Корейцы о микропенисах которых теперь знают намного больше людей:

В Северной Корее открыли первый компьютерный клуб. Зал рассчитан на 300 мест, но интернет там только государственный — интранет под жёстким контролем.

Про железо не говорят, игры называют «простыми». Зато посетителям разрешают смотреть фильмы из официального списка и даже пользоваться ксероксом. На входе проверяют паспорта и фиксируют каждого в журнале.

Час игры стоит 5000 вон (около 500 рублей). Гейминг пускает корни даже в диктатуре

Будни #bootstrap, #lab, #home_lab

У меня в пакетнике нет способа передать какую-то информацию от пакета "наверх". То есть, у меня флаги наследуются вниз по дереву зависимостей, а вверх - нет.

Почему так?

Потому что такая фича делает язык описания сборки пакетов turing complete, и построение пакетов не обязательно будет сходящейся процедурой:

{% if not X %}
{% yield X %}
{% endif %}

(тут yield - гипотетическая конструкция, которая поднимает флаг до корня)

Свойство это важное, его терять не хочется.

Где это может быть полезно?

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

Эту проблему можно решить, например, так - собрать один большой бинарник python, в котором были бы все модули, нужные этим 10 программам, и использовать этот python для их запуска. Или, например, программы могут декларировать нужные им фичи от ядра.

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

Увы.

Но, благодаря тому, что моя home lab катается не просто через IX, а через простенький IaC поверх IX, то такая возможность у меня есть - я просто руками собираю все нужные модули для всех сервисов, и передаю их в пакет с python.

https://github.com/pg83/lab/blob/master/lab/cg.py#L986-L992 - вот сервис декларирует все свои зависимости.

https://github.com/pg83/lab/blob/master/lab/cg.py#L1569 - вот я их агрегирую

https://github.com/pg83/lab/blob/master/lab/cg.py#L1598 - передаю в пакет, собирающий python, через флаг py_extra_modules

https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1576520-bcachefs-outlines-plans-for-shipping-as-a-dkms-out-of-tree-kernel-module?p=1576592#post1576592

Взгляд #Kent на всю ситуацию:

"Look, being in the kernel hasn't been good for bcachefs-the-project.

Sure, it's brought in more users, but the drama has kept other developers away, it's constantly freaking out funders, and it takes over the public discussion when I'd much rather be talking about the technical stuff and the cool things we're doing. Things are nice and calm and peaceful, and low drama, when Linus isn't causing problems.

Coincidence? I think not.

The drama has taken an enormous toll over the entire history that bcachefs has been upstream, so now I'm just happy to leave it all behind and focus on the code.

Being in the kernel is pointless if it means too many cooks in the kitchen screwing things up, derailing the project and adding nothing.

I'd rather have a smaller project, and do it well. It's still going to keep growing, because there's nothing else out there that can compete.

You guys who keep assuming that code is meaningless if it's not in the kernel are entirely missing the point. I had a real userbase before it was even merged, and now gauging by the number of people who keep asking when DKMS is going to be ready and even volunteering to help out and contributing code for that - I don't think it's actually going to hurt my userbase that much.

I'm worked my ass off to get this done, and I didn't do that just so I could have idiots who've never remotely worked on a modern filesystem and don't give a crap about making reliable filesystems screw this up.

Now, I'm going to get my nice calm and peaceful coding life back. I've had my backup plan in the works for a year now; I drove down to Colombia over the winter where I can live comfortably off just my Patreon in case I lose my funding, and I've got plenty of money in the bank besides that. I've spent a career making sure I can work independently, and it's worked out just fine.

So now, I get to spend the next few years doing nothing but finishing erasure coding, online fsck, failure domains, some really nice management tooling, and maybe if I'm lucky I'll get into send/recv too. And spending my time hiking and playing music when I'm not coding.

Without a care in the world, and answerable to no one"

Я, короче, решил сам проверить, как эти uutils работают в качестве замены системных утилит.

Собрал, перезагрузился, и, мааама-дорогая, у меня в 2 раза больше процессов, чем обычно.

Отлаживать особо не пришлось, виновника обнаружил самый простой pstree:

# pstree
...
... bash---env---sleep
...

Да, у кучи программ обнаружился очень странный parent - env.

env - максимально примитивная тулза, она выставляет заданные env переменные, и делает exec в программу, которая ей указана в самом конце cmd line (то есть, "исчезает").

(она обрабатывает те самые шебанги #!/usr/bin/env python3, отсюда и масштаб проблем)

Только в случае rust uutils:

* она или делает fork + wait

* или, еще хуже, еще и перегоняет данные через pipe между child и parent, как это делает python subprocess, например

(код не читал, что там именно - сказать не могу)

Школьники такие школьники - тесты проходить научились, а суть понимать - нет.

Я, от греха подальше, эту хтонь выключил - https://github.com/pg83/ix/commit/6b1c02c2cde2f3e229a33772ae04b2bf0e995081

UPD: нам тут пишут, что, в последней версии, починили - https://github.com/uutils/coreutils/commit/cab307a40e9b3f12c812e3ba6207b55f4fa21496

Писал как-то про #pthread_cancel - https://www.tgoop.com/itpgchannel/817

"Не используйте ее, нигде и никогда. Ее поведение максимально плохо определено, и, в реальной жизни, введет вас в какой-нить deadlock. Потому что тестов на этот участок кода вы все равно не напишите"

Вот, в копилочку проблем - https://eissing.org/icing/posts/rip_pthread_cancel/

TL:DR - авторы curl захотели научиться отменять резолв dns через getaddrinfo, но не учли, что функция эта читает файл /etc/gai.conf, через fopen. И иногда они отменяли это чтение файла, что приводило к утечке памяти.

Красивое, спасибо подписчику за ссылку!

Возрождение легенды 🌝

Язык Perl поднялся с 27 на 10 место в рейтинге Tiobe
https://www.opennet.ru/opennews/art.shtml?num=63878

Причины роста популярности Perl не ясны, никаких значимых событий, связанных с данным языком, кроме очередного ежегодного релиза Perl 5.42, в этом году не происходило. По предположению руководителя TIOBE высокая позиция в рейтинге связана с большим числом книг по Perl, продаваемых в интернет-магазине Amazon (например, число книг по Perl в 4 раза превышает PHP и в 7 раз Rust).

Также упоминается учащение публикации промежуточных релизов Perl 5 и вытеснение Perl 6/Raku из поля зрения (Perl 6 занимает 129 место). Из гипотез также отмечается возвращение интереса к языку Perl из-за его возможностей обработки текста и продвинутых регулярных выражений, что стало востребовано с развитием AI-платформ. Пик популярности Perl пришёлся на март 2003 года, когда данный язык поднялся на 3 место в рейтинге, после чего началось постепенное снижение популярности Perl.

Из других набирающих популярность языков выделяется язык Си, который по сравнению с сентябрём прошлого года поднялся на 3 место, вытеснив на 4 место язык Java. Кроме того, с 11 на 9 место поднялся язык Pascal, с 15 на 13 - R, с 26 на 14 - Ada, с 21 на 17 - Assembler. Первое и второе места продолжают занимать Python и С++. Кроме Java популярность снизилась у языков SQL (с 9 на 11 место), Fortran (10 → 12), PHP (13 → 15), Rust (14 → 18), Matlab (12 → 19) и Kotlin (18 → 20).

Индекс популярности TIOBE строит свои выводы на основе анализа статистики поисковых запросов в таких системах, как Google, Bing, Wikipedia, Amazon, YouTube и Baidu.

Ссылка на рейтинг
https://www.tiobe.com/tiobe-index/

Российский убийца игровых движков Unreal и Unity оказался на грани банкротства Коммерсантъ. Проект скорее всего остановят. В 2022 году сообщалось, что на его развитие направят 1 млрд рублей, а в будущем все игры в России будут или созданы на Nau Engine, или не получат госаккредитацию. @bankrollo

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

TL;DR - вышла новая samba.

Вроде, ничего интересного, но:

"Добавлена поддержка использования в качестве транспорта для SMB3 протокола QUIC. Для использования QUIC на стороне сервера требуется загрузка модуля ядра quic.ko, который пока поставляется отдельно, но скоро будет принят в основной состав ядра Linux"

https://lore.kernel.org/all/cover.1751743914.git.lucien.xin@gmail.com/

Божечки, ну что же за срань-то? Зачем, эти злые люди продолжают тянуть всякое в ядро? Им дыр в #ksmbd не хватает (https://www.tgoop.com/itpgchannel/3387)?

Технически реализация, конечно, потрясает (нет) своей технологичностью - она требует наличие демона в userspace, чтобы заниматься handshake:

"For kernel consumers, they can initiate a handshake request from the kernel to userspace using the existing net/handshake netlink. The userspace component, such as tlshd service [2], then manages the processing of the QUIC handshake request"

Скорость этой поделки тоже, скажем так, "впечатляет":

QUIC(disable_1rtt_encryption) vs. TCP:
  
    UNIT        size:1024      size:4096      size:16384     size:65536
    Gbits/sec   QUIC | TCP     QUIC | TCP     QUIC | TCP     QUIC | TCP
    ────────────────────────────────────────────────────────────────────
    mtu:1500    3.09 | 4.59    4.46 | 14.2    5.07 | 21.3    5.18 | 23.9
    ────────────────────────────────────────────────────────────────────
    mtu:9000    4.60 | 4.65    8.41 | 14.0    11.3 | 28.9    13.5 | 39.2

Я так понимаю, движ начался после https://arxiv.org/html/2310.09423v2:

"QUIC is expected to be a game-changer in improving web application performance. In this paper, we conduct a systematic examination of QUIC’s performance over high-speed networks. We find that over fast Internet, the UDP+QUIC+HTTP/3 stack suffers a data rate reduction of up to 45.2% compared to the TCP+TLS+HTTP/2 counterpart. Moreover, the performance gap between QUIC and HTTP/2 grows as the underlying bandwidth increases"

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

Вот я как в воду глядел :(

#AMDVLK

Ну и закономерный исход из https://www.tgoop.com/itpgchannel/3116 - https://www.opennet.ru/opennews/art.shtml?num=63886 https://discourse.gnome.org/t/stepping-down-as-libxml2-maintainer/31398

Такой сегодня день.

КДПВ из https://www.tgoop.com/mem_b0lt_Genona/300

Теперь к важным новостям - jetbrains запилили возможность построчно отлаживать constexpr/consteval выражения в C++ - https://blog.jetbrains.com/clion/2025/09/introducing-constexpr-debugger/

Я, к своему стыду, за столько лет, как эти штуки появились, так и не начал их серьезно использовать, разве что, как замену enable_if, в виде if constexpr. Мне, когда нужен генератор state machine для движка регулярок, я беру внешний ragel/antlr/flex/bison/whatever, и не стремлюсь все утоптать в прокрустово ложе C++.

И, да, мой код при этом работает быстрее, чем твой, %username%!

#cplpl_doomed

Goldman Sachs says AI still not showing up in companies' bottom lines
Article, Comments

oh no…

TikTok to Be Acquired by Oracle, Silver Lake and Andreessen
Article, Comments

А хорошо быть первым гопником на раене, взять, и на гоп-стоп отнять компанию!

https://www.kommersant.ru/doc/8042457

Власти Афганистана отключили интернет «для предотвращения безнравственности»