я упомянул комментарий АНБ относительно безопасных языков, новость о котором датируется примерно теми же датами

Лучше читайте первоисточники, а не интерпретации журналистов. Администрация Байдена агитирует за повышение безопасности софта на всех уровнях. Но ни кто до сих пор не понимает как и в чем эту самую безопасность измерять, чтобы в итоге решить повысилась она или понизилась и на что ушли бюджетные деньги.

Предыдущая попытка разработать такие методики ни к чему не привела. Это известная проблема, о чем собственно и упоминантся в докладе. Остальное там вода, про то как все страшно, и как бы стало все замечательно, если бы такие методики изменения все же появились.

Google выделил миллион долларов на улучшение переносимости между С++ и Rust

Кстати, причины такой щедрости здесь недавно описывали: у Google Chrome, который в основном написан на C++, возникли проблемы с boringssl, после того как куски последней переписали на Rust. Команда не смогла с этим справиться в режиме обычного багфиксинга. Поэтому кто-то сверху решил закидать проблему деньгами. Речи о каких-то глобальных изменениях для Гугла естественно не идёт. В глобальном плане, разработку захватывают нейронки, а им в общем-то без разницы на каком языке сочинять код.

нужно быть осторожнее с лицензиями. Существуют такие лицензии, которые, например, разрешают использование в виде исходного кода, но не в виде статически слинкованного объектного файла. Не зная этого, условия можно случайно нарушить

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

обираться со старой glibc. Glibc имеет обратную совместимость — если что-то собрано на Ubuntu 17, на Ubuntu 20 оно тоже заработает. А вот обратное не гарантируется.

Они периодически ломают и обратную совместимость на уровне ABI. В общем случае можно ориентироваться на мажорную версию. Но в истории были нюансы. Подробнее тут https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html.

Интересно, где здесь прибыль для банка? На первый взгляд одини расходы, но ведь так не может быть.

Есть хороший разбор книг Эванса и Вернона в трёх частях https://vaadin.com/blog/ddd-part-1-strategic-domain-driven-design.

Первая часть посвящена стратегическому уровню DDD, который концентрируются на проблемах бизнеса: доменах, под-доменах и их классификации. Для каждой проблемы обозначаются границы её решения, i.e. bounded context. Это то место, внутри которого будет жить реализация. Здесь же способы интеграции между отдельными решениями, исходя из проблематики бизнеса.

Во второй части описыватся тактический DDD, с фокусом на моделировании: entities, aggregates, domain events - все что вы любите.

В третьей части он показывает как можно вписать такую модель в приложение, на примере Hexagonal Architecture. Здесь модель получает конкретную реализацию и обрастает снаружи технической обвязкой: api, UI, базами данных и т.п.

Микросервисы это просто один из паттернов реализации приложения, построенный на идеях компонентной архитектуры. Есть и другие. Например вы можете завернуть их в приложение для десктопа или телефона, сделав ближе к пользователю. Или монолита - упростив развертывание. Или ... Все будет зависеть от остальных требований.

кроме репозитория, другие механизмы будут уметь восстанавливать сущности из БД, то у вас размазываются знания об одной сущности на несколько механизмов

Мы же занимаемся информационным моделированием, а не стараемся сделать копию реального мира? В информационной системе одна и та же физическая сущность может предоставляться разными моделями.

Требования к данным, которые предъявляет UI, часто сильно расходятся с точкой зрения на них со стороны ETL. Поэтому вполне логично, в решении использовать разные принципы и механизмы.

По поводу разных БД, можно упростить - "у вас есть две разных БД", это более реальная ситуация

Многие люди, чтобы переместить коня из точки А в точку Б, могут это сделать верхом. Профессиональные жокеи могут ехать вверхом на двух одновременно. Это немного против физики, и не так удобно, как на одном, за то публика в восторге. Но не стоит пытаться повторить их опыт, когда требуется перегнать два самолёта - здесь нужно использовать другие подходы. ;)

Ситуация с БД чем-то похожа. Совсем не сложно выполнять транзакции последовательно: сначала в одну базу, затем в другую. Но пытаться усидеть на двух открытых транзакциях для разных баз одновременно это тоже против физики. Для таких ситуаций есть неплохой разбор https://vaadin.com/blog/ddd-part-1-strategic-domain-driven-design.

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

Согласен, здесь проблема ещё в том, что терминология заимствуя разными источниками и разобраться потом о чем вообще речь без полного контекста может быть нереально.

вам нужно получить менеджеров по какому то критерию, касающегося менеджеров.

Обычно в таких случаях рекомендуют использовать другие паттерны, например CQRS. Т.е. обновления идут через репозиторий где обеспечивается атомарность операций, а выборки данных для UI - простыми queries.

что мне сделать если один репозиторий mysql, другой postgresql, третий вообще не sql. Кто должен уметь держать три разные транзакции? Контроллер?

Архитектор). Лечить по симптомам это плохая идея, нужно разобраться зачем у вас так сделано.

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

Репозиторий отвечает за сохранение агрегата, обеспечивая в том числе и атомарность операций при сохранении всех entities, входящих в этот агрегат. Т.е. транзакции находятся внутри операции, внутри репозитория.

Делать по отдельному "репозиторию" на каждый тип entity (в стиле Table Module) и пытаться оркестровать транзакции снаружи это антипаттерн, поскольку противоречит изначальной идее.

Если мы все задизайнили правильно, но UseCase по прежнему имеет дело с несколькими агрегатами, тогда это Workflow. Скорее всего здесь будет обеспечиваться eventually consistency, нежели транзакционность. В каких-то случаях можно срезать углы с помощью внешней транзакции на базу данных. Но прежде лучше сто раз подумать.

Одно дело перепродавать шмотки из условной Турции, другое дело - высокотехнологичный и наукоёмкий продукт. Нужна очень высокая степень доверия к партнёрам или безрассудства, чтобы ввязываться. К тому же, нищий регион не сулит ни чего экстраординарного в плане прибыли.

Starlink это технология двойного назначения (продуктовая линейка для DoD называется Starshield). Как и в другие проекты Маска, в них вложена куча бюджетных денег.

запустила производство

Раньше бы сказали "наладила производство". У слова "запустить" есть два, практически противоположных, смысла.

Няня на пять дней в неделю обойдётся в 200 баксов в месяц

Говорят, что в замкадье за такие деньги можно нанять целого программиста. Не супер-стар, но с каким-никаким образованием он будет.

В итоге, вместо того, чтобы позволить другим инвесторам использовать дешёвую рабочую силу, тем самым вливая капиталы в страну

Я так понимаю, что этап дёшевой рабочей силы с околонулевыми налогами внутри там уже проходили - полвека даже не прошло. Тогда "инвесторы" их так же грабили, только гораздо более активно. Ведь все, что им по сути нужно это природные ресурсы и дешёвая рабочая сила. Смысл туда вливать капиталлы, когда их нужно наоборот выводить?

Зависит от того как считать: https://bugs.kde.org/show_bug.cgi?id=482780 . Стабильной инфраструктуры до сих пор нет - ребята бегут впереди лошади и пытаются тянуть её за собой.

Если она невозможна, то что за чудо произошло в KDE 6?

tl;dr по ссылке: мы сделали чудо, но оно ещё пока не готово.

Другими словами, демон Лапласа невозможен не только во всех физически возможных (эвереттовских) мирах, но и во всех математически возможных мирах

Более общий вопрос: познаваема-ли Вселенная до конца, в принципе? Если ответ отрицательный, то в этом мире есть вполне законное место для нашего незнания. А это значит, что отсутствие детерминизма перестаёт быть проблемой - возможна любая магия! Детерминизм - субъективен. Отсутствие его - объективно.

Закономерность из 41 месяца: через 6 + 6 + 6 + 6 + 6 + 6 + 6 + 5 = 41 месяц, или около 3,4 года

Интересно, как у них вообще получалось отслеживать такие закономерности? 3,4 это ведь довольно большой срок в жизни человека, который наверняка мог быть наполнен решением каких-то более насущных проблем, в то нелегкое время.

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