Apple работала с ARM со времён Newton из прошлого века. Флагманскими устройствами были iPod и iPhone на Arm. Для них Intel был риском. А M1 - это просто десятилетняя эволюция их A Series, от A4 к A14 Bionic. Где там риск?
К 2020 Arm уже давно расцвел, одна только продукция Anapurna от маленьких Mikrotik до серверов Amazon на Graviton. В рейтинге суперкомпьютеров с 2020 лидирует Arm от Fujitsu и тп.
Потрудитесь пояснить, где вы нашли противоречие? Природа ключа контексто-зависимая. Авторы БИКа выдумали ключ, в этот момент он суррогатный. Вы его использовали в своей системе как натуральный. Если вы станете выдумывать в своей системе новые ключи, они будут суррогатными. Для той системы, которая будет использовать вашу кодификацию, они могут стать натуральным. Природа ключа определяется средой. В идеале - естественной, но там очевидных ключей нет, поэтому в мире выстраиваются различные организационные иерархии (организация - это прежде всего способ упорядочивания, а не юридическое лицо), чтобы вести кодификацию.
Я нет, это вы так полагаете, судя по вашему первому комментарию.
И как из моего первого комментария, что натуральные ключи не выдумывают это следует? Вам не кажется, что выдуманное по определению являетеся суррогатным? Как из сути, так и из этимологии этого слова?
Индустриальность стандарта не входит в критерии первичного ключа.
Как это связано с тем, что я сказал про возможность использования ISO 3166 в качестве натурального ключа для стран? Вы пытаетесь опровергнуть то, что я не утверждал. Может хотите сказать, что коды ISO не являются хорошим, авторитетным кандидатом на эту роль?
Вот именно, среда и бизнес-домен могут быть любыми, главное что они внешние по отношению к проектируемой системе. Определять их может любая другая система, а не только “целые организации, управляющие соответствующими справочниками”.
Так это мои слова, что “средой, бизнес-доменом”. Цитата, которую вы вырвали из контекста, говорила лишь о том, что некоторые справочники с натуральными ключами уже ведутся большими организациями. И очевидно, что репутационный и качественный индекс у них достаточно высоки. Тое есть вряд ли появится две страны с одинаковым ISO-кодом или одна страна с двумя или страна завтра поменяет свой ISO-код. Но взять на себя “организацию справочников” может любая система.
Так, что один из авторов теории реляционных БД называет первичным ключом произвольный набор полей, которые уникально идентифицируют запись.
Я уже давно хотел поинтересоваться, отличаете ли вы первичный ключ от натурального/суррогатного. Оказывается нет, в принципе. Первичный ключ - это констрейнт, который в каноническом виде пишется как ALTER TABLE ... ADD CONSTRAINT ... PRIMARY KEY ... . Он может накладываться на натуральный ключ, суррогатный, композитный, вы можете сделать первичный ключ по хэшу содержимого или иной функции. Натуральный/суррогатный ключ - это данные, отражающие природу появления этого ключа. Они возникают до первичного и содержатся непосредственно в CREATE TABLE. У меня в одной таблице может быть, скажем VIN автомобиля, являющийся его натуральным ключом, а может быть простой автоинкремент - суррогатный ключ, а PK я могу создать по любому из них. Я обсуждаю первую фазу - данные, а вы пытаетест навесить констрейнты. На что?
Выделение отдельно суррогатного ключа появилось позже в “Relations and Entities” (1976)
Вы статью хоть читали? Она фокусируется на концепции суррогата, поскольку не всегда можно идентифицировать сущность по совокупности ей аттрибутов и возникала проблема определения тождественности при изменении этих аттрибутов. И, как говорили авторы: “A key is still needed to uniquely identify the surrogate.”. Природу возникновения ключа они вообще не обсуждали, главным требованием была неизменяемость.
То есть все ключи натуральные, если они не суррогатные.
Это круговой, неоперациональный классификатор, основанный на недоопределённом предикате. Из категории “пациент либо жив, либо мёртв”.
“код страны по ISO 3166, БИК банка” никто не выдумывал, они сами появились?
Все ключи кто-то выдумал. Вы же не полагаете, что натуральные - природного или божественного происхождения? Поэтому всё сводится к уровню их определения. Для ISO код 643 применительно к РФ был очевидно суррогатным, поскольку нет такой f, что f(РФ) = 643 и далее по всему списку. Для вас, как проектировщика БД, он будет натуральным, поскольку определён индсутриальными стандартами, то есть средой, бизнес-доменом. Натуральный/суррогатный = среда/разработчик.
A Relational Model of Data for Large Shared Data Banks - E. F. CODD
Как мне интерпретировать статью, где натуральные или суррогатные ключи упомянуты ровно ноль раз, в контексте моей цитаты про таковые? А также хаотические вырезки из текста, где природа “part number” никак не определена, а я говорил исключительно о ней.
Ставите Visual Studio Community Edition на винду, подключаете телефон, дев аккаунт, создаёте iOS-приложение, деплоите на телефон и о чудо… работает. Заходите в папочку с билдом, а там подписанный ipa.
Автор вообще не понимает, что такое натуральный ID. Сам дискурс, что его надо выдумывать, противоречит их концепции и в ход идут примеры ненатуральных ключей, вроде e-mail или паспортов, которые идентификаторами персоны не являются в принципе, это ассоциированные сущности. Натуральный, это когда вы берёте код страны по ISO 3166, БИК банка и т.п. За каждым натуральным ID существуют целые организации, управляющие соответствующими справочниками и единственным аргументом менять их на суррогатные ключи является вопрос оптимизации данных при высокой IO-стоимости ключа, особенно в связанных таблицах.
Зачем он C#-разработчикам, у которых есть F#? С exhaustive pattern matching, pipe-operator, мутабельными переменными и computational expression, на которых красиво делаются и state machines, и ранний return. Всё это в итоге можно собрать в один бинарник как в Go.
При "правильной формализации" у вас специалисты являются прямым объектом исследования, обозначенном непосредственно в заголовке статьи. И фраза "не о специалистах речь" говорит о попытке подмены исходной задачи. Какой логикой или инженерной практикой вы руководствовались в данном случае или сработал человеческий фактор?)
Хотите поговорить о знаниях и учебниках? Давайте. С точки зрения логики, знания и их скрижали не имеют никакого смысла, если не будут трансформированы в действия, вооруженные этими знаниями. А знаете как в быту называют исполнителей таких действий? Специалисты. И мы опять возвращаемся на круги своя))
И вы пытаетесь сказать, что любой человек, вне зависимости от бэкграунда, включая предыдущие знания, опыт и т.п., прочитав некий набор литературы (к нему есть отдельный вопрос), выполнит одну и ту же задачу совершенно одинаково? И на это не повлияет ни опыт участия в других проектах, ни время дня, ни настроение? Вы вообще понимаете, как формируется подобная литература? Темпоральность знаний, как они эволюционируют, творческая составляющая и т.п.?
Вы так частно говорите о "формальности", но формально "проблема разрешения неразрешима" и над доказательством этого трудились лучшие умы вроде Гёделя, Тарского, Тьюринга, Чёрча и других. И сильной стороной человека была именно вероятностная модель, которую называли творчеством. Хотя, в вашей системе все эти мужи просто читали неправильные книги, но подождите... они как раз пошатнули основы математики и других очень формальных и очень логичных дисциплин, заставив переосмыслить и переписать многие книги. И по сей день идёт битва между ZFC и HoTT как фундамента, казалось бы, самой точной науки.
Даже если вы формализуете львиную долю инженерного труда, значит она может быть изложена на формальных языках, включая языки программирования, что уничтожит человека-инженера как актора в целом. Как дальше вы будете действовать в вашей системе?
Парадокс в том, что стандартизация лучших инженерных стандартов нужна и важна. У нас катострофически не хватает хорошей литературы. Я сам работаю над таковой. Но то, как вы это преподносите вызывает много вопросов и мне кажется противоречащим инженерной логике в своей базе.
Ваша модель не выдерживает даже простой логической проверки. Возьмите на рынке труда 10 человек, которые декларируют себя как те самые специалисты из вашего заголовка. Дайте каждому из них нетривиальную задачу. Сравните их ответы, а потом расскажите нам про вероятностную модель ИИ. Поиск специалиста - вероятностная модель, сам специалист - вероятностная модель, которая может выдавать разный результат даже в зависимости от времени суток.
Трамп, главы Nvidia, Oracle, OpenAI, SoftBank, Cisco и других встречаются в Эр-Риаде, анонсируют крупнейший инвестиционный проект Stargate UAE. А оказывается это шейх мелкой фарцовкой по перепродаже чипов занимается.
Это его последний срок, а VAT сложен в администрировании. Возможность его введения обсуждается давно, в том числе проводится ревью в книге из моего комментария выше, но основное препятствие - как раз сложность.
Не совсем понял, как усложнение задачи ведёт к её решению? Как можно апеллировать к НДФЛ Швеции, если в ЕС есть страны с 10% НДФЛ, а в США штаты с ~50%.
Давайте проведём простой мысленный эксперимент. Представьте, что Трамп ввёл не пошлины, а НДС. То есть технически, все импортируемые в США товары стали на 20% дороже. По вашему мнению, причин для возмущения нет, ведь для НДС работает "правило шведского НДФЛ". Тогда почему возмущаются пошлинами в таком же размере, ведь математически расходы идентичны?
Мне кажется, что через НДФЛ вы встали на дискурс потребителя. И с этой точки зрения НДС - это всегда зло, поскольку он его основной плательщик. Но этот налог стимулирует экспорт и защищает от импорта. Он выгоден для тех, кто создаёт максимальную добавленную стоимость на своей территории, то есть для производства. Вы не платите НДС при экспорте, но зачитываете входящий НДС затраченный на производство экспортируемых продуктов.
Трамп непосредственно артикулирует к внешнеторговому балансу и хочет из страны-потребителя сделать страну-производителя. Оперативно ввести VAT он не может, поэтому приходиться его симулировать через тарифную политику, как в мысленном эксперименте выше.
Я полагаю а тезисе про НДС речь идёт и о том, что для конечного потребителя в США европейские машины не облагаются, в то время как Американские в Европе - да.
Мне кажется это вы перепутали "эволюцию" и "теорию эволюции Дарвина". На всякий случай напомню, что речь шла о "человеке, который будет уметь отбрасывать информационный шум и не вестись на простые ответы без самостоятельного вхождения в контекст". Вы уверены, что для этого нужны генетические мутации?
Увы и ах, большинство ВУЗов на самом деле полностью игнорируют вопросы композиции приложений. Учать обжигать кирпичи, но не складывать из них постройки.
Как можно всерьёз воспринимать статью про SOLID, в которой слово тест упоминается... ноль раз? Даже такой маленький штрих уже кричит, что может быть больше одной реализации IOrderCalculator. Более того, в TDD вы скорее всего начнёте с интерфейса, его моков и тестов ещё задолго до реализации. Аналогично ни слова по DI/IoC-контейнеры как мощные инструменты по организации слабосвязных сложных приложений.
Очевидно, что SOLID, как и подавляющее большинство существующих концепций, не идеален. Но если отбросить очевидные агрументы о том, что любой инструмент надо применять с умом, остаётся сплошная вкусовщина. Постоянная отсылка к какому-то мифическому "контексту", но ни одного примера, где следование принципам SOLID несёт очевидный вред. Фактически вся контраргументация сводится к небольшому росту количества кода. Но и это ничем не обосновано. Я могу с лёгкостью привести пример как, скажем, атомизация (SRP, ISP) классического паттерна репозиторий приводит напротив к росту повторного использования, обобщений и как итог - существенному сокращению объёма кода.
Как итог, на одну чашу весов кладётся копеечная экономия на определении интерфейсов, а с другой - качественная дизайнерская работа над определением этих самых интерфейсов, из которых потом растёт API. А в чём аргумент? Начать использовать интерфейсы, когда уже серьёзно припрёт? Где та тонкая грань, когда можно переходить на нормальный дизайн? Может в статье есть метрики, как сильно описание интерфейсов усложняет жизнь?
Поддерживаю предыдущих ораторов. Сравнивать OLAP-колумнары, учитывая огромногое количество специфики, с OLTP и in memory… Автор попробовал бы поддать RPS на Clockhouse или DuckDB и сравнил бы с Redis. А почему бы и нет…
CentOS уже давно не за кем не следует, ибо закончила свой путь в 2021. В качестве альтернатив RedHat выступают AlmaLinux, RockyLinux. CentOS Stream идёт как тестовая платформа для RedHat, Fedora Server - ещё более актуальные версии и, конечно, самый свежак - Fedora Server Rawhide.
Я об этом сам случайно узнал от Миловидова в последнем Release Call 24.8. В документации или других источниках до данного момента не попадалось. Попробовал провести простой тест агрегирующей проекции в ReplacingMergeTree и всё печально... агрегат продолжает агрегировать полностью игнорируя факт replace'а))
Вы заменили 100 мужиков с косами и плугами на один технологичный комбайн. TCO снизился в десять раз. Инвестора разбежались с испуга?
Они никогда не объясняли стратегию расширения и роста потребляемыми ресурсами. Где вы такое взяли?
Apple работала с ARM со времён Newton из прошлого века. Флагманскими устройствами были iPod и iPhone на Arm. Для них Intel был риском. А M1 - это просто десятилетняя эволюция их A Series, от A4 к A14 Bionic. Где там риск?
К 2020 Arm уже давно расцвел, одна только продукция Anapurna от маленьких Mikrotik до серверов Amazon на Graviton. В рейтинге суперкомпьютеров с 2020 лидирует Arm от Fujitsu и тп.
Потрудитесь пояснить, где вы нашли противоречие? Природа ключа контексто-зависимая. Авторы БИКа выдумали ключ, в этот момент он суррогатный. Вы его использовали в своей системе как натуральный. Если вы станете выдумывать в своей системе новые ключи, они будут суррогатными. Для той системы, которая будет использовать вашу кодификацию, они могут стать натуральным. Природа ключа определяется средой. В идеале - естественной, но там очевидных ключей нет, поэтому в мире выстраиваются различные организационные иерархии (организация - это прежде всего способ упорядочивания, а не юридическое лицо), чтобы вести кодификацию.
И как из моего первого комментария, что натуральные ключи не выдумывают это следует? Вам не кажется, что выдуманное по определению являетеся суррогатным? Как из сути, так и из этимологии этого слова?
Как это связано с тем, что я сказал про возможность использования ISO 3166 в качестве натурального ключа для стран? Вы пытаетесь опровергнуть то, что я не утверждал. Может хотите сказать, что коды ISO не являются хорошим, авторитетным кандидатом на эту роль?
Так это мои слова, что “средой, бизнес-доменом”. Цитата, которую вы вырвали из контекста, говорила лишь о том, что некоторые справочники с натуральными ключами уже ведутся большими организациями. И очевидно, что репутационный и качественный индекс у них достаточно высоки. Тое есть вряд ли появится две страны с одинаковым ISO-кодом или одна страна с двумя или страна завтра поменяет свой ISO-код. Но взять на себя “организацию справочников” может любая система.
Я уже давно хотел поинтересоваться, отличаете ли вы первичный ключ от натурального/суррогатного. Оказывается нет, в принципе. Первичный ключ - это констрейнт, который в каноническом виде пишется как
ALTER TABLE ... ADD CONSTRAINT ... PRIMARY KEY .... Он может накладываться на натуральный ключ, суррогатный, композитный, вы можете сделать первичный ключ по хэшу содержимого или иной функции. Натуральный/суррогатный ключ - это данные, отражающие природу появления этого ключа. Они возникают до первичного и содержатся непосредственно в CREATE TABLE. У меня в одной таблице может быть, скажем VIN автомобиля, являющийся его натуральным ключом, а может быть простой автоинкремент - суррогатный ключ, а PK я могу создать по любому из них. Я обсуждаю первую фазу - данные, а вы пытаетест навесить констрейнты. На что?Вы статью хоть читали? Она фокусируется на концепции суррогата, поскольку не всегда можно идентифицировать сущность по совокупности ей аттрибутов и возникала проблема определения тождественности при изменении этих аттрибутов. И, как говорили авторы: “A key is still needed to uniquely identify the surrogate.”. Природу возникновения ключа они вообще не обсуждали, главным требованием была неизменяемость.
Это круговой, неоперациональный классификатор, основанный на недоопределённом предикате. Из категории “пациент либо жив, либо мёртв”.
Все ключи кто-то выдумал. Вы же не полагаете, что натуральные - природного или божественного происхождения? Поэтому всё сводится к уровню их определения. Для ISO код 643 применительно к РФ был очевидно суррогатным, поскольку нет такой f, что f(РФ) = 643 и далее по всему списку. Для вас, как проектировщика БД, он будет натуральным, поскольку определён индсутриальными стандартами, то есть средой, бизнес-доменом. Натуральный/суррогатный = среда/разработчик.
Как мне интерпретировать статью, где натуральные или суррогатные ключи упомянуты ровно ноль раз, в контексте моей цитаты про таковые? А также хаотические вырезки из текста, где природа “part number” никак не определена, а я говорил исключительно о ней.
Ставите Visual Studio Community Edition на винду, подключаете телефон, дев аккаунт, создаёте iOS-приложение, деплоите на телефон и о чудо… работает. Заходите в папочку с билдом, а там подписанный ipa.
Автор вообще не понимает, что такое натуральный ID. Сам дискурс, что его надо выдумывать, противоречит их концепции и в ход идут примеры ненатуральных ключей, вроде e-mail или паспортов, которые идентификаторами персоны не являются в принципе, это ассоциированные сущности. Натуральный, это когда вы берёте код страны по ISO 3166, БИК банка и т.п. За каждым натуральным ID существуют целые организации, управляющие соответствующими справочниками и единственным аргументом менять их на суррогатные ключи является вопрос оптимизации данных при высокой IO-стоимости ключа, особенно в связанных таблицах.
Зачем он C#-разработчикам, у которых есть F#? С exhaustive pattern matching, pipe-operator, мутабельными переменными и computational expression, на которых красиво делаются и state machines, и ранний return. Всё это в итоге можно собрать в один бинарник как в Go.
При "правильной формализации" у вас специалисты являются прямым объектом исследования, обозначенном непосредственно в заголовке статьи. И фраза "не о специалистах речь" говорит о попытке подмены исходной задачи. Какой логикой или инженерной практикой вы руководствовались в данном случае или сработал человеческий фактор?)
Хотите поговорить о знаниях и учебниках? Давайте. С точки зрения логики, знания и их скрижали не имеют никакого смысла, если не будут трансформированы в действия, вооруженные этими знаниями. А знаете как в быту называют исполнителей таких действий? Специалисты. И мы опять возвращаемся на круги своя))
И вы пытаетесь сказать, что любой человек, вне зависимости от бэкграунда, включая предыдущие знания, опыт и т.п., прочитав некий набор литературы (к нему есть отдельный вопрос), выполнит одну и ту же задачу совершенно одинаково? И на это не повлияет ни опыт участия в других проектах, ни время дня, ни настроение? Вы вообще понимаете, как формируется подобная литература? Темпоральность знаний, как они эволюционируют, творческая составляющая и т.п.?
Вы так частно говорите о "формальности", но формально "проблема разрешения неразрешима" и над доказательством этого трудились лучшие умы вроде Гёделя, Тарского, Тьюринга, Чёрча и других. И сильной стороной человека была именно вероятностная модель, которую называли творчеством. Хотя, в вашей системе все эти мужи просто читали неправильные книги, но подождите... они как раз пошатнули основы математики и других очень формальных и очень логичных дисциплин, заставив переосмыслить и переписать многие книги. И по сей день идёт битва между ZFC и HoTT как фундамента, казалось бы, самой точной науки.
Даже если вы формализуете львиную долю инженерного труда, значит она может быть изложена на формальных языках, включая языки программирования, что уничтожит человека-инженера как актора в целом. Как дальше вы будете действовать в вашей системе?
Парадокс в том, что стандартизация лучших инженерных стандартов нужна и важна. У нас катострофически не хватает хорошей литературы. Я сам работаю над таковой. Но то, как вы это преподносите вызывает много вопросов и мне кажется противоречащим инженерной логике в своей базе.
Ваша модель не выдерживает даже простой логической проверки. Возьмите на рынке труда 10 человек, которые декларируют себя как те самые специалисты из вашего заголовка. Дайте каждому из них нетривиальную задачу. Сравните их ответы, а потом расскажите нам про вероятностную модель ИИ. Поиск специалиста - вероятностная модель, сам специалист - вероятностная модель, которая может выдавать разный результат даже в зависимости от времени суток.
Трамп, главы Nvidia, Oracle, OpenAI, SoftBank, Cisco и других встречаются в Эр-Риаде, анонсируют крупнейший инвестиционный проект Stargate UAE. А оказывается это шейх мелкой фарцовкой по перепродаже чипов занимается.
Это его последний срок, а VAT сложен в администрировании. Возможность его введения обсуждается давно, в том числе проводится ревью в книге из моего комментария выше, но основное препятствие - как раз сложность.
Не совсем понял, как усложнение задачи ведёт к её решению? Как можно апеллировать к НДФЛ Швеции, если в ЕС есть страны с 10% НДФЛ, а в США штаты с ~50%.
Давайте проведём простой мысленный эксперимент. Представьте, что Трамп ввёл не пошлины, а НДС. То есть технически, все импортируемые в США товары стали на 20% дороже. По вашему мнению, причин для возмущения нет, ведь для НДС работает "правило шведского НДФЛ". Тогда почему возмущаются пошлинами в таком же размере, ведь математически расходы идентичны?
Мне кажется, что через НДФЛ вы встали на дискурс потребителя. И с этой точки зрения НДС - это всегда зло, поскольку он его основной плательщик. Но этот налог стимулирует экспорт и защищает от импорта. Он выгоден для тех, кто создаёт максимальную добавленную стоимость на своей территории, то есть для производства. Вы не платите НДС при экспорте, но зачитываете входящий НДС затраченный на производство экспортируемых продуктов.
Трамп непосредственно артикулирует к внешнеторговому балансу и хочет из страны-потребителя сделать страну-производителя. Оперативно ввести VAT он не может, поэтому приходиться его симулировать через тарифную политику, как в мысленном эксперименте выше.
Дебаты на эту тему уже давно идут. Можно заглянуть, например, в кэмбриджский учебник Amazon.com: Value Added Tax: A Comparative Approach
Я полагаю а тезисе про НДС речь идёт и о том, что для конечного потребителя в США европейские машины не облагаются, в то время как Американские в Европе - да.
Мне кажется это вы перепутали "эволюцию" и "теорию эволюции Дарвина". На всякий случай напомню, что речь шла о "человеке, который будет уметь отбрасывать информационный шум и не вестись на простые ответы без самостоятельного вхождения в контекст". Вы уверены, что для этого нужны генетические мутации?
На примере исследований нейропластичности мозга и устройств вроде BrainPort, нужно намного меньше 50 лет, чтобы человек научился видеть языком.
Увы и ах, большинство ВУЗов на самом деле полностью игнорируют вопросы композиции приложений. Учать обжигать кирпичи, но не складывать из них постройки.
Как можно всерьёз воспринимать статью про SOLID, в которой слово тест упоминается... ноль раз? Даже такой маленький штрих уже кричит, что может быть больше одной реализации IOrderCalculator. Более того, в TDD вы скорее всего начнёте с интерфейса, его моков и тестов ещё задолго до реализации. Аналогично ни слова по DI/IoC-контейнеры как мощные инструменты по организации слабосвязных сложных приложений.
Очевидно, что SOLID, как и подавляющее большинство существующих концепций, не идеален. Но если отбросить очевидные агрументы о том, что любой инструмент надо применять с умом, остаётся сплошная вкусовщина. Постоянная отсылка к какому-то мифическому "контексту", но ни одного примера, где следование принципам SOLID несёт очевидный вред. Фактически вся контраргументация сводится к небольшому росту количества кода. Но и это ничем не обосновано. Я могу с лёгкостью привести пример как, скажем, атомизация (SRP, ISP) классического паттерна репозиторий приводит напротив к росту повторного использования, обобщений и как итог - существенному сокращению объёма кода.
Как итог, на одну чашу весов кладётся копеечная экономия на определении интерфейсов, а с другой - качественная дизайнерская работа над определением этих самых интерфейсов, из которых потом растёт API. А в чём аргумент? Начать использовать интерфейсы, когда уже серьёзно припрёт? Где та тонкая грань, когда можно переходить на нормальный дизайн? Может в статье есть метрики, как сильно описание интерфейсов усложняет жизнь?
Поддерживаю предыдущих ораторов. Сравнивать OLAP-колумнары, учитывая огромногое количество специфики, с OLTP и in memory… Автор попробовал бы поддать RPS на Clockhouse или DuckDB и сравнил бы с Redis. А почему бы и нет…
CentOS уже давно не за кем не следует, ибо закончила свой путь в 2021. В качестве альтернатив RedHat выступают AlmaLinux, RockyLinux. CentOS Stream идёт как тестовая платформа для RedHat, Fedora Server - ещё более актуальные версии и, конечно, самый свежак - Fedora Server Rawhide.
Я об этом сам случайно узнал от Миловидова в последнем Release Call 24.8. В документации или других источниках до данного момента не попадалось. Попробовал провести простой тест агрегирующей проекции в ReplacingMergeTree и всё печально... агрегат продолжает агрегировать полностью игнорируя факт replace'а))