The end of the monopolistic web era?

Except maybe in totalitarian states, you cannot ever have a single publisher. Most large cities had multiple independent newspapers. In recent years, we saw a surge of concentration regarding newspaper and television ownership. However, this was accompanied by a surge of online journalism. The total number of publishers increased, if nothing else. Yet you can more easily have a single carrier/distributor than monopolistic publisher. For example, the same delivery service provides me my newspaper as well as a range of competing newspapers. The delivery man does not much care for the content of my newspaper. A few concentrated Internet providers support diverse competing services. The current giants (Facebook, Twitter and Google) were built initially as neutral distributors. Google was meant to give you access to all of the web’s information. If the search engine is neutral, there is no reason to have more than one. If twitter welcomes everyone, then there is no reason to have competing services. Newspapers have fact-checking services, but newspaper delivery services do not. Of course, countries like Russia and China often had competing services, but…

https://lemire.me/blog/2022/02/07/the-end-of-the-monopolistic-web-era/

В своих хождениях по мукам Wayland наткнулся на интересный видос. https://www.youtube.com/watch?v=cj02_UeUnGQ

Если кто не знает, то Кейт Пакард - очень крутой в прошлом чувак. Cairo, xrandr - это все был большой прорыв в OSS графике. #fontconfig - тоже он, да. Правда, в последние годы он несколько зашкварился(кстати, напомню, что это анти-SJW, и, даже, правый, блог), но это не отменяет его былых заслуг, мы же не леваки какие.

Весь видос смотреть не обязательно, но вот часть про GNU и Столлмана, со слов очевидца, очень даже прикольно(с 28 минуты).

Про python #gil.

* Оказывается, я пропустил классное интервью с автором этого мега набора патчей:
https://lukasz.langa.pl/5d044f91-49c1-4170-aed1-62b6763e6ad0/

* https://github.com/microsoft/mimalloc/issues/475
Коллеги уже лезут патчить mimalloc, потому что использование аллокатора из mimalloc - часть nogil проекта. Мне прямо хочется им туда написать, что они идиоты и не лечатся совсем не подумали про static linking, но, как обычно, решил, что обойдусь парой дефайнов, а они там путь упарываются со своими symbol visibility, как хотят.

———
https://nvidianews.nvidia.com/news/nvidia-and-softbank-group-announce-termination-of-nvidias-acquisition-of-arm-limited

Big news, nvidia больше не покупает ARM. И очень жаль, потому что от этого альянса можно было бы ожидать чего-нить очень интересного.

https://www.phoronix.com/scan.php?page=news_item&px=Intel-RISC-V-International

Зато Intel вступает в RISC-V. В какой-то интересный выхлоп от Intel в плане RISC-V я верю гораздо меньше, Intel толстые, старые, и осторожные. Скорее, они участвуют везде и нигде одноврменно, для галочки, не делая ничего по существу, и проедая накопленный интеллектуальный капитал.

———
https://www.phoronix.com/scan.php?page=news_item&px=Firefox-Wayland-X11-Stats

Я чувствую, что со своей ориентацией на static linking + Wayland + clang, я, конечно, найду своего пользователя.

https://www.phoronix.com/scan.php?page=news_item&px=Chimera-Linux-2022
https://www.phoronix.com/scan.php?page=news_item&px=OpenMandriva-Lx-4.3

С удивлением узнал, что Mandriva тоже с Clang. Это, конечно, хорошо. В предыдущую мою попытку построить Clang-based дистрибутив было существенно сложнее, чем сейчас.

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

Привычка - это хорошо.

Поэтому объявляю аттракцион невиданной щедрости!

1000-ному подписчику я лично* приеду и устанвлю Mix на ноутбук!

* - выезд в пределах ТТК.

Кому что, а голому вшивому - баня. Я снова про #fontconfig

Периодически я запускаю strace на свои процессы, и смотрю, какие файлы открывают программы, чтобы:

* Они не лезли по системным путям, типа /usr

* Чтобы они не лезли в папки с установленными статическими библиотеками(если лезут, значит, я где-то забыл выделить общие данные из кода библиотек, и после gc цикла программы перестанут работать)

Почти все графические программы лезут в /usr/share/fonts, и я, наконец, решил это побороть.

Нашел пути в устанавливаемом конфиге, https://github.com/freedesktop/fontconfig/blob/master/fonts.conf.in#L28, убрал, пересобрал, проверил. Программы все равно лезут в /usr, за шрифтами.

Нашел добавление этих путей в исходниках. https://github.com/freedesktop/fontconfig/blob/master/src/fccfg.c#L2670 Ну так, на всякий случай - вдруг кто-то удалит из конфига, и не получит нужных шрифтов. Вспомнил недобрым словом Кейта Пакарда, удалил, пересобрал, проверил - все равно лезут.

Запустил греп еще раз. На этот раз увидел, что отличилась система сборки - https://github.com/freedesktop/fontconfig/blob/master/meson.build#L213 Вспомнил недобрым словом Кейта, его маму, папу, и прочих коллег по цеху X.org.

Короче, на этот раз все сработало. Больше программы в /usr не лезут.

Очень, очень надежная система.

PS: мое творчество:
https://github.com/pg83/mix/blob/main/pkgs/lib/fontconfig/data/mix.sh
https://github.com/pg83/mix/blob/main/pkgs/lib/fontconfig/t/mix.sh#L26

Обещал про динамическую линковку в OSS. #GNOME

Есть такая библиотека - #glib. И в ней типа есть возможность использовать tls. Ну, была раньше. Потом поддержку tls вынесли в отдельную либу - https://gitlab.gnome.org/GNOME/glib-networking, видимо, по лицензионным соображениям(раньше же openssl и GPL были несовместимы), но это же OSS, поэтому glib продолжает делать вид, что умеет в tls.

При попытке использования tls glib пытается загрузить glib networking, и сыпется, если это невозможно. Отделили, да.

Поэтому всякий там код, который хочет использовать tls, проверяет наличие этого загружаемого модуля во время компиляции:

Checking if "GIO has real TLS support" with
 dependencies glib-2.0, gmodule-2.0,
 gobject-2.0, gio-2.0 runs: NO (1)

Реально, вдумайтесь в происходящий цирк.

Конечно, тут же и кольцевая зависимость образовалась(потому что этот плагин продолжает зависеть от glib, а как же иначе).

К счастью, libc от проекта gnu очень хорошо умеет жить с кольцевыми зависимостями(UPD: а до последнего времени был пиздец о n^3 - https://habr.com/ru/post/451208):

"В системе динамического связывания реализован новый алгоритм сортировки DSO, использующий метод поиска в глубину (DFS) для решения проблем с производительностью при обработке зацикленных зависимостей."

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

Выскажу такую мысль - примерно треть проблем, которые можно увидеть на разных форумах про Linux(ладно, я на LOR смотрел) - это проблемы разбиения приложения на плагины. Неработающий звук - 100% посреди цепочки какой-нить pipewire не может найти плагин с alsa. Неработающее ускорение видео в браузере - 100% Mesa не может найти плагин для какого-нить vdpau. И так далее.

Обычно причины этому следующие:

* Пути не стандартизованы. Драйвер от nvidia может положить интерфейс для ускорения декодирования не туда, где его ожидает увидеть mesa.

* Не прописана зависимость, плагина просто нет на FS

* Плагин сломан(не хватает каких-то символов), не загружается.

Тестов на это все нет, и не будет.

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

https://www.youtube.com/watch?v=u9R4RoaLSIM #abi
https://habr.com/ru/company/yandex/blog/649497/

Я всегда спрашиваю, "а чо там с range-based for loop", и мне не отвечают. Комитет С++ уже много-много лет ищет пуговицу, потому что его взяли в заложники IBM(и другие компании, которым важно поддержание ABI) и несколько старых дедов(которым важно поддержать свое слабеющее влияние), и не дают решать насущные проблемы.

Пуговицу искать, конечно, очень увлекательно, но перспективы С++ сейчас, конечно, очень туманны. #cppcom

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

Я, конечно, все понял, только я не понял, на какие исходники, принадлежащие РФ, мне дадут позырить.

Сегодня я выступаю в роли https://ru.wikipedia.org/wiki/%D0%90%D1%80%D0%BC%D1%8F%D0%BD%D1%81%D0%BA%D0%BE%D0%B5_%D1%80%D0%B0%D0%B4%D0%B8%D0%BE

Нас спрашивают, мы отвечаем!

Q: Антон, вот ты, в который раз, пишешь, что в С++ все плохо, а что делать-то?
A:

В рамках текущей организационной структуры С++ комитета ничего сделано быть не может.

Посмотрите, сколько там голосов у американских компаний, и сколько у российских, например(спойлер - у российских 0, Антон туда ездит не как представитель Яндекса, а как представитель всей России(если я верно все понимаю)). Поэтому небольшое число голосов компаний, которым важна обратная совместимость, могут превалировать над всеми разработчиками С++ всего мира, которым ABI нафиг не всралось, они все равно и так все пересобирают, так же, как в Rust.

Ну и текущая структура комитета настроена на воспроизведение самое себя, впрочем, как и любая другая структура. Люди, которым там что-то не нравится, и они публично об этом заявляют, каким-то образом оказываются вне этой структуры, я периодически на такие coming out кидал ссылки.

Мне кажется, у MANGA(основные потребители С++) могло бы хватить сил, чтобы переломить эту ситуацию. Например, сказать, что они делают С++v2, и что clang будет его поддерживать. Если бы они сказали, что сделают в С++v2 нормальные lifetimes, и правильную обработку ошибок, я бы пошел двигать переход на их стек, думаю, как и многие другие.

Может ли кто-то, кроме MANGA? Сомневаюсь. Да нет, не сомневаюсь, не может.

А они сделают? Думаю, нет, думаю, им ОК новая волна в виде Rust. Зачем чинить С++ - это сложно, муторно, долго, и немодно, когда можно просто воспользоваться новым хайпом? Если бы не Rust, то стимул починить С++, конечно, был бы существенно выше, я был бы оптимистичнее про судьбу С++.

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

Я, конечно, пытаюсь свои патчи отправлять в upstream, но чаще всего оказывается, что оунеры кода - те еще негодяи.

Вот, отправил свой патч про отказ от double fork. -20 строк кода, сплошное упрощение и улучшение. Как думаете, какие шансы у патча? Я вангую, что околонулевые.

https://github.com/swaywm/sway/issues/6828

Теорминимум по #bootstrap

Разные команды вкладывают в это понятие очень разные смыслы.

Кто-то - что в процессе сборки не должны участвовать бинарные блобы(за исключением возможного минимума). Понятие "бинарный" часто не конкретизируется. Java VM, python pickle - чаще всего "бинарные блобы". По мне, так программы для "раннебутстрапного" forth от бинарных блобов не отличимы, но это никого не останавливает.

Кто-то идет еще дальше, и считает, что автосгенеренные исходники использовать тоже нельзя. Эти люди занимаются бутстрапом flex/bison/ragel/etc. К сожалению, на этом пути лежит пропасть и бездна - configure скрипты. Уважаемым коллегам или приходится переписывать систему сборки части кода, или бутстрепать код в бездну веков. Это, например, GUIX.

Кто-то больше всего печется о "чистоте" результата. Ну, чтобы рандомный Васян мог воспроизвести md5-equal result. Используется ли при этом бинарный seed, или нет, коллег особо не волнует. Это, например, Nix.

Я тут стараюсь придерживаться прагматичной стороны - я не перестраиваю configure на ранних этапах bootstrap, но когда у меня готов perl, начинаю перестраивать. Типа, получить 95% результата за 5% денег. Если у меня 1000 пакетов, и в 995 из них я убираю сгенеренные файлы, поверхность для атаки я уменьшаю многократно, и вполне достаточно для практических целей. Бинарный seed я, фактически, использовать не могу, потому что чаще всего он рассчитывает на наличие glibc.

Еще интересная дихотомия - какой язык использовать в качестве "изначального". Чаще всего это компилятор С, потому что достаточно высокороуровнево(не надо мудохаться с ассемблером и гипервизором в кольце 0), можно дотащить цепочку, куда угодно, большинство системного кода написано на С.

Я тяну цепочку с С++, потому что поддерживаю Darwin, а там единственный компилятор, который умеет рожать Mach-O - это clang. Есть проекты, которые тащут tcc/scc под Mach-O, я с удовольствием за ними слежу(потому что С++, это, конечно, многовато).

Наверняка есть попытки затащить эту цепочку с Rust, но я о чем-то таком успешном пока не слышал. В принципе, все для этого есть - uutils, наверняка есть простой компилятор С на Rust, шелл точно есть. Если тащить с Rust, то, конечно, с собой нельзя брать Cargo. Весь смысл теряется, если добавить cargo в seed, да и не спортивно это. Как #mrustc тянет cargo через свой minicargo - это же песня.

Про патч в #sway у меня, конечно, плохие предчувствия. Судя по активности в репе, разработчики как забухали в начале января, так в строй и не вернулись - ревью не отревьюены, и все такое.

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

Я перенес построение realm/environment из пакетного менеджера в граф построения пакетов. Звучит странно, и непонятно, зачем это нужно?

#realm - definition ***

realm/environment - это материализованное в FS множество пакетов. Если говорить просто - папочка, которая содержит кучу симлинков на файлы из других папочек(пакетов). Куча симлинков образует некоторую сущность(realm, env), которая самодостаточна для выполнения какой-то задачи.

Чтобы совсем просто:

* realm из пакета-бинаря и пакетов-шаренных библиотек является достаточной сущностью для запуска этого бинаря.

* realm из пакетов busybox + runit + kernel достаточен для запуска компьютера.

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

Теперь построение папки с симлинками погружено в тот же граф, что строит пакеты. Фактически, с точки зрения системы realm стал таким "пакетом с пакетами", если вы понимаете, о чем я.

Почему это вообще важно? Теперь вторая часть моего сегодняшнего рассказа!

Когда я писал, что переехал на mix на своем ноутбуке, конечно, это был многоступенчатый процесс.

* Сначала у меня в системе был только root, все пакеты строились от него, все было в едином namespace. Я так отлаживал пригодность модели "куча папок с симлинками" для управления файлами системы вообще.

* Потом я завел пользователя mix. На этом этапе построение пакетов и realm/env выполнялось от пользователя mix, я сам был залогинен в mix, но сервисы уже работали от root. Я так отлаживал свою модель эскалации привилегий и модель "пакеты не от root". Это уже почти норм, кроме того факта, что неловким движением можно снести всю пакетную базу.

* С пятницы я живу в модели "пакетный менеджер - это демон, который крутится от пользователя mix, принимает команды на управление пакетной базой, и выполняет в соответствие со своей моделью безопасности". Важно отметить, что примитивная команда - это не "установи в систему bin/bash", а ПОЛНОЕ описание(граф с зависимостями) того, как построить бинарник bash, и установить его в систему. Я эту модель опишу в следующих сериях.

Я думаю, тут важность моего рефакторинга стала очевидной. Одно дело, когда поверхность взаимодействия в точке эскалации привилегий - это хорошо формализованный граф, который можно провалидировать вдоль и поперек перед выполнением(ну, вот, как ядро валидирует eBPF программы), другое дело - "хорошо формализованный граф" + "говна самовар" вида "а вот тут, сбоку, сделай еще папочку с кучей симлинков и дерни там чего-нить" ** .

Короче, модель вполне жизнеспособна, пакетный менеджер я отселил в socket activation daemon*, с точки зрения модели безопасности мне все очень нравится.

* забавно, как можно продать одно и то же говно, но разными словами. Мой socket activation daemon - это "mix gen-graph —json | ssh mix@localhost /bin/mix execute —stdin" (напомню, что мои su/sudo - это suidless программы, которые делают ssh на localhost)

** как вы уже, наверное, поняли, прямо сейчас я ничего не валидирую. Я знаю, что это возможно, я сделаю это позже, но слона надо есть по частям. #sec_model

*** я намеренно выбрал странное слово realm, а не всем знакомое env, потому что, конечно, мой realm похож там на env из Nix, но не настолько, чтобы считать их одним и тем же. Чтобы в голове не было путаницы, я выбрал похожее, но другое, слово. IMHO получилось хорошо, удобно, и однозначно(меньше путаницы в голове это уж точно)

https://tjournal.ru/news/533398-rukovoditeli-ibm-vo-vnutrenney-perepiske-nazyvali-rabotnikov-starshe-40-let-dinozavrami-kotorye-dolzhny-vymeret

Новость, конечно, позитивная, потому что это сразу решит проблемы с дедами в Комитете С++, мешающими этот стандарт двигать вперед. Or not? #cppcom

https://www.opennet.ru/opennews/art.shtml?num=56691 #lust

У меня пара свежих мыслей на тему:

* За пределами big tech мало кто понимает, что ядро на голой сишечке - это леденящий душу пиздец. Intel-у, например, вполне OK.

* За последние несколько месяцев я прочел довольно много кода драйверов(kernel, mesa), чтобы понять, что средний драйвер - это очень тупая штука, которая берет набор за-OR-енных generic флагов, превращает их в набор за-OR-енных device specific флагов, и пишет это число в порт. Управления памятью в среднем драйвере или нет, или очень мало.

* Желание читать мануалы про за-OR-енные device flags чаще всего антикореллирует с желанием прогать на высокоуровневом языке.

Поэтому мое IMHO - в текущем виде это проект для себя и узкого круга компаний, типа Facebook, которые "понимают". Я считаю, что текущее целеполагание проекта - странное. Ну перепишут Гугл драйвера для своих TPU, а дальше что? Intel и средний "kernel hacker" это не купят.

IMHO правильным целеполаганием было бы "переписать tcpip stack"(потому что новые алгоритмы для congestion control, конечно, проще на Rust/C++), или "переписать шедулер". Впрочем, возможно, истинное целеполагание именно такое, просто оно не озвучивается. Это, конечно, было бы хорошо. Мне не нравится Rust, но вот писать на С я в ядро точно не полезу, а на Rust полезу.

https://codeberg.org/dnkl/foot/src/tag/1.11.0/README.md#user-content-xtgettcap #terminfo

Хорошая же тема, да, чтобы эмулятор терминала сразу отдавал свои capabilities, без всяких terminfo database, да?

Как бы это сделал вменяемый разработчик? Например, чтобы эта функция терминала отдавала TERMINFO запись as is, чтобы ее можно было там передать в curses, и использовать сразу? В крайнем случае, машинно-понимаемой трансляцией в json/xml/yaml.

Но, очевидно, Том #Хуйкин(разработчик xterm), индус #Ковид(разработчик Kitty), и неизвестный мне разработчик #foot(ссылку на опус которого про поддержку sync updates я тоже кидал), к такому решению, конечно, прийти не могли - это ж всего 3 строчки кода, и победную реляцию не напишешь!

Поэтому, конечно, все это сериализуется в промежуточный непонятный формат(с потерей в процессе), а клиенты потом должны восстанавливать. Зато можно будет написать еще 10 победных реляций про очередную перемогу в стиле "а мы поддержали еще 5 полей из terminfo"(несовместимым, конечно, образом).

———
https://www.opennet.ru/opennews/art.shtml?num=56703
https://www.opennet.ru/opennews/art.shtml?num=56704
https://www.opennet.ru/opennews/art.shtml?num=56700
https://www.opennet.ru/opennews/art.shtml?num=56699

Слушайте, вот вы понимаете, зачем люди клепают эти производные Debian с нескучными обоями? Меня, как автора настоящего, интересного, дистрибутива, это все, конечно, напрягает.

———
https://lobste.rs/s/adr60v/single_binary_executable_packages

Очередной срачик static vs. dynamic. Автор, конечно, говорит дельную вещь - а давайте, типа, сразу все приложения готовить в виде одного исполняемого файла, но он, наверное, сам так не пробовал, и не понимает, в чем проблема такого подхода.

Кстати, совсем забыл. Если вы такой же фанат машграфа, как и я - обязательно подпишитесь на https://www.facebook.com/sergey.tsyptsyn/

Вернусь к вчерашней ссылке про static vs. dynamic.

https://lobste.rs/s/adr60v/single_binary_executable_packages#c_xoxpbs

1) Там подняли интересные темы про статическую линковку в Rust и Go.

2) СЯУ, что в Rust нет кросс-компиляции. Ну, точнее, есть, по модели CMake(#cross #cmake на сайте написано, что есть, а cargo таки оперирует одним графом). Я это еще заприметил, когда только начал им пользоваться, но у меня не хватало уверенности, чтобы об этом сказать.

———
https://codeberg.org/dnkl/fuzzel/pulls/53

Автор #foot классный. Я как-то писал про проблему первого кадра в sway, так вот, коллега тоже обратил на нее внимание, и даже предложил решение.

———
https://rtpg.co/2022/02/13/your-own-sudo.html

Товарищи, если кто-то в вашей окружности решит написать sudo на python, пристрелите его.

* питон загружает много модулей
* авторам so-шек обычно нет выхода, кроме как заполучать параметры для себя через env
* man secure_getenv, и связанные с загрузкой so #suid-ными бинарями CVE.

———
https://gankra.github.io/blah/text-hates-you/
http://rastertragedy.com/RTRCh0.htm

Классные тексты про text rendering и text shaping.

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

Кстати, про шрифты - связка Inter + IBM Plex мне нравится даже больше, чем набор шрифтов в macOS.

https://github.com/skarnet/execline/issues/9

Успел посраться с автором s6, по поводу утилиты #execline. По очкам я, конечно, победил, но мое предложение он, конечно, отверг.

———
Будни бутстрапа.

Как-то писал про то, что система зависает, если убить sway неправильно. Оказалось, что она не зависает, а просто прекращает как-то реагировать на ввод. Фикс, что характерно, я подсмотрел в трекере sway. https://github.com/pg83/mix/blob/main/pkgs/bin/fixtty/main.c https://github.com/swaywm/sway/issues/4540

Фикс этот, конечно, не может войти в sway, и его вряд ли примут mainstream дистрибутивы. Я не гордый, я дергаю программулю перед каждым новым логином:

https://github.com/pg83/mix/blob/main/pkgs/bin/mingetty/runit/mix.sh#L16

У меня лучший дистрибутив для работы со sway!

Заодно выпилил хаки, и прибиваю stale процессы почем зря.

Отдельно скажу, что вот эти tty - это, конечно, кошмар. Про них Линус и так говорил, что не понимает, как они работают, но после того, как к ним привязали KMS/DRM, стало вообще худо. https://lwn.net/Articles/343828/

Еще интересный факт - у меня, когда я еще использовал Fedora, регулярно не просыпался ноутбук после сна. Теперь я смог это раздебажить. Оказывается, драйвер amdgpu начинал сыпать стектрейсами, sway падал в кору, и система приходила в волшебное состояние, которое я описал выше. Теперь же она из него замечательно выходит сама, и я увидел все корки в dmesg.

Простота - это хорошо. В федоре у меня не было никакой возможности увидеть эти трейсы. Чинить баги, а не документировать их в wiki, как делают Arch/Gentoo - тоже.

Кстати, amdgpu не сыпет этими стектрейсами в 5.17, ждем релиза.

https://mobile.twitter.com/marcan42/status/1494213855387734019 #asahi

У меня чет знатно долбануло от заявления этого долбоеба разработчика Asahi Linux Гектора Мартина:

"Well, this is unfortunate. It turns out Apple's custom NVMe drives are amazingly fast - if you don't care about data integrity."

Давайте я вам расскажу, что там происходит.

Гектор жалуется, что macos "читит" - некорректно реализует семантику fsync(а я, кстати, позволю себе напомнить, что macos - сертифицированный Unix, в отличие от), и, за счет этого, обгоняет его драгоценный Ляликс на бенчмарках NVMe. И отмечает, что, если в Apple ткнуть паяльником, то после ребута она потеряет данные.

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

Вы в macos теряли данные после ребута? Я не терял.

Если инженеры Apple:

* Хорошо отладили свою ОС, настолько, что ГАРАНТИРОВАТЬ, что OS сбросит буфера FS и контроллера на диск при нажатии на кнопку Reset.

* На всякий случай добавили туда батарейку, и написали код, который по исчерпании батарейки сбросит буфер и выключит комп.

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

Я напомню, что вот та семантика fsync, о которой пишет Гектор, нужна, когда твою OS пишут красноглазые пионеры без тестов. Потому что заставить весь зоопарк FS флашить данные пофайлово - невозможно. Заставить FS флашить данные корректно - невозможно https://danluu.com/file-consistency/ https://www.deconstructconf.com/2019/dan-luu-files Убедиться, что весь зоопарк контроллеров флашит данные корректно - невозможно.

Единственное, на что можно(а на самом деле и нельзя) полагаться - что fsync сделает большой мега-барьер по всему стеку, и скинет данные на диск насколько это возможно надежно, в такой ситуации.

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

Ну чо, норм, но не надо говорить, что macos "читит", это вводит людей в заблуждение. "if you don't care about data integrity" - Гектор просто не понимает, насколько, а самое главное, КАК, Apple заботится о integrity.

И, кстати, еще такая мысль - подобные штуки поясняют, почему Apple против Хакинтошей, и почему Хакинтоши - так себе мысль. macOS работает на железе, которое сделано по несколько другой философии, это нужно учитывать