Подписка здесь должна идти без кавычек, поскольку картриджи, присланные в рамках программы Instant Ink, перестают работать, как только пользователь перестает платить. Из-за чего у пользователей подгорает, т.к. они-то думали, что платили всего лишь за своевременную поставку картриджей, а не за привилегию печатать на собственном принтере.
Это Ваше наоборот очень похоже, наоборот, на "точно также". В НН тоже картой дешевле, чем наличкой, причем сразу на 5 рублей. И отмазка про продажу водителем не проходит - билет (в случае маршруток) покупается всегда у водителя, отличается только способ оплаты и цена.
Защищаются от обратной ситуации (помнится, была некоторое время неопределенная ситуация с тем, будет ли сам Cloudflare блокировать запросы от российских IP); довольно логично, чтобы внешние ссылки российских сайтов на всякие там jQuery и прочие шрифты ссылались не на Google/Azure/Cloudflare, а на гипотетический RusCDN, который не отключит их клиентов по желание своей левой пятки.
Ну и будет меньше некрасивых ситуаций, когда РКН очередной раз блокирует условный GitCloudGoogleHub, а потом у русских потребителей ломаются русские же сайты.
Утверждение "кому надо - купят" не работает для Open Source. Разработчикам, к примеру, медиакомбайнов типа ffmpeg, vlc или gstreamer необходим доступ к десяткам различных стандартов ISO, за доступ к которым им (en masse) никто не заплатит.
Сделка в 2018 году сорвалась в последний момент, потому что США надавили на Голландию. И с тех пор так и идет блокада. Теперь уже США требуют не продавать в Китай оборудование DUV и современные чипы. Почему? Ну вот, как мне видится, одна из предпосылок (из отчета National Security Commission on Artificial Intelligence 2021 года):
Put simply: the U.S. supply chain for advanced chips is at risk without concerted government action.Rebuilding domestic chip manufacturing will be expensive, but the time to act is now. The United States should commit to a strategy to stay at least two generations ahead of China in state-of-the-art microelectronics and commit the funding and incentives to maintain multiple sources of cutting-edge microelectronics fabrication in the United States
Как Америка может обогнать Китай на два поколения? Очевидно, надо а) строить современные фабрики на территории США (привет, Intel), и б) тормознуть сам Китай (привет, санкции).
Что именно должны были сделать КПК, чтобы санкций не было? Да ничего они не могут сделать, если США поставили себе цель "догнать и обогнать", стать глобальными лидерами в производстве современной электроники. Разве что можно перестать быть соперником США и лечь под них, стать ее де-факто колонией, как это произошло с Южной Кореей (зато туда EUV продают без проблем).
Вы не учитываете, что пластину в техпроцессе необходимо экспонировать несколько раз. Для сложной микросхемы типа современного процессора с многими слоями металлизации - вроде бы ~20 раз. Так что 10 литографов при полной загрузке за сутки изготовят 1 (одну) пластину, и ~20 000 эльбрусов.
Тут скорее не музыкальный инструмент, а программа, которая в несколько кликов создает "произведение" за тебя. Вот только в такого рода программах семплы лицензированы, а контент, который пошел на обучение Midjourney - нет. Так что эта артистка может претендовать на авторство текстового концепта, а вот на авторство картинки скорее могут претендовать сотни художников, чьи картины были использованы как исходные данные.
На мой взгляд, во второй задаче подходит решение "Аристотель - честный безопасный водитель, Мёрдок и Сунь-цзы - лгущие убийцы".
Сунь-цзы: Мёрдок и Аристотель говорят правду
Мёрдок лжет -> Сунь-цзы лжет.
Мёрдок: Чтобы выжить, выбирайте Сунь-цзы или Аристотеля.
Выбор Сунь-цзы приводит к смерти -> Мёрдок лжет.
Аристотель: Если хотите жить, не выбирайте Мёрдок.
Мёрдок убийца, Аристотель говорит правду.
В оригинале "To survive, choose Sun Tzu, or choose Aristotle". Имхо и оригинальное утверждение, и перевод можно понимать как "любой выбор будет безопасен -> ни Сунь-цзы, ни Аристотель не являются убийцами"; по смыслу же приведенного решения похоже, что идея автора была "хотя бы один из двух не является убийцей", из чего делается вывод "Мёрдок лжет -> оба остальные убийцы -> Мёрдок не убийца".
Если посмотреть на даты, то скорее всего у банка вообще не было возможности продлить договор; единственный шанс исправить дело заключался в том, чтобы перестать использовать движок, но на это они пойтить не смогли.
C++ код с классами, конструкторами и деструкторами будет столь же быстрым, как и аналогичный ему C код, но будет более коротким (если код написан правильно, с обработкой ошибок) и читабельным - это если не пользоваться идиоматическими C++ возможностями, а именно виртуальными функциями и исключениями (отключить вообще исключения опциями компилятора).
Если брать более идиоматический код и добавить виртуальные функции, то они будут либо чуть-чуть медленнее, чем применяемые в таких ситуациях C ссылки на функции (если ссылки лежат прямо в структуре - но тогда C-шный вариант будет более прожорлив по памяти), либо такими же по скорости (если C-шный вариант применяет эрзац таблицы виртуальных методов по типу struct ..._ops), либо даже чуть быстрее (32-битный Windows ABI - thiscall более оптимально использует регистры, чем cdecl)
Если добавить исключения как идиоматическую замену кодам ошибок, то код становится еще компактнее и быстрее в "обычном" случае безошибочной работы (т.к. большинство ABI обеспечивают бесплатный try/except, а в C требуется проверка кода ошибки везде). Исключение - тот же 32-битный Windows ABI, где try не бесплатен.
1) CRT - это C runtime library, оно как раз для C.
2) код, написанный на C, обычно без особого геморроя можно скомпилировать C++ компилятором. Вы утверждаете, что код, скомпиленный компилятором C, выполняется быстрее, чем тот же код, скомпиленный компилятором C++?
3) В windows ядро в основном написано на C++. Если говорить про *nix, то системные библиотеки пишут на C потому, что а) у него более стабильный ABI и б) их начали писать 40 лет назад - традиция-с.
Если GPL действительно не совместим с российским законодательством - это отличный повод поправить законодательство :) Хотя если это действительно так, то интересно, как RedHat и Oracle продавали в России свои дистрибутивы.
Для ПО рассматривать импортозамещение исключительно как "написано русскими для русских" - это глупость, синдром NIH национального масштаба. Пусть нам стало недоступно проприетарное ПО зарубежным производителей. Остается доступным огромнейший слой open source, на написание которого были потрачены миллионы человеко-лет; доступно ПО, которое УЖЕ прошло те самые десятилетия развития, на которое уже было потрачено время высококвалифицированных разработчиков, которое уже было отшлифовано миллионами пользователей. И теперь предлагается отбросить все это богатство только на основании того, что его делали не только русские, но и иностранцы?
Импортозамещение - суть обеспечение собственной независимости от иностранного влияния типа санкций. РЕД ОС (Альт/.../подставьте свой любимый Linux) решает эту задачу в нише ОС общего назначения (пусть даже там 99.9% "забугорного" кода) и, увы, альтернативы ему не видно. Никто почему-то пока не написал русскую гениальную ОС, и ждать, пока ее может быть напишут, нельзя.
И использование - https://chromium.googlesource.com/chromium/src/+/refs/heads/main/chromeos/hugepage_text/hugepage_text.cc - выделяют блок hugepage памяти (выровненный по границе большой страницы), копируют данные, задают правильные права, а потом вместо всех телодвижений по переезду - просто делают mremap этого блока по исходному адресу (тоже выровненному по границе большой страницы - это важно). Имеющиеся маппинги автоматически закрываются, hugepages переезжают на новый виртуальный адрес и все.
Случайно наткнулся на патч от Google, где они решали ту же проблему для Chrome; там фиксили mremap с thp. Т.е. может быть в новых версиях Linux можно вместо всей этой чешуйни просто после копирования данных сделать mremap их по оригинальному адресу; но надо смотреть на выравнивание адресов данных.
Еще одна альтернатива была бы вынести весь функционал по переезду данных с page cache на anonymous в отдельный DSO, и тогда не надо было бы городить весь этот изврат с написанием кода, работающего в любом месте в памяти.
Глянул одним глазком на доклад (надо будет посмотреть целиком :)) - действительно, товарищи эту статью видели и им действительно это не подходит; им нужно кровь из носу использовать Transparent Huge Pages, потому они и занимаются нехорошими вещами.
"Нормальному" же пользователю, которому надо сервис почему-либо загнать в HP, будет в 95% случаях проще настроить линукс, как описано в той статье )
Причем в одном из подходов в huge pages грузится, похоже, код прямо из (специально подготовленного) файла штатно без каких-либо телодвижений. Т.е. " Linux позволит использовать большие страницы только для анонимных отображений в память - то есть, для тех, которые не связаны ни с каким файлом " не вполне верно. На что также намекает строчкаFileHugePages в /proc/meminfo
Таки да - главное это РЕЕСТР. Неважно, что абстрактный 1С:УправлениеВсемИВся или там Компас3D чисто российского производства - без вхождения в реестр российского ПО он не будет считаться таковым. Соответственно его будет трудно продавать. Если минцифры пропишет себе в методички, что ВСЕ российское ПО обязано запускаться на конкретной ОС, то производителю придется как-то выкручиваться. И если у того же абстрактного Компаса под капотом весь UI завязан на DirectX, то Wine может оказаться самым рациональным способом для производителя снова стать "русскими". Wine имхо можно без сильной натяжки отнести к "библиотечному слою" типа JRE/Mono/Gtk+/Qt, которые идут в комплекте с ОС или же с ПО, и не выделяются отдельно.
Windows-под-Linux оставим на совести тех, кто это сделал. А что касается Linux и Wine, то они вполне себе могут быть использованы для импортозамещения - если есть российский разработчик, который легальным образом их поставляет и осуществляет поддержку заказчиков (а это так и есть, соответственно Астра/Базальт/РЕД и Etersoft). Можно, конечно, понимать импортозамещение, как переход на ПО исключительно и полностью российского производства - ОС чисто русской разработки, компиляторы чисто русской разработки, все библиотеки чисто русской разработки, вообще все до последнего бита чисто русское - но это нереалистично и иррационально. Собственно, и "единый реестр российского ПО" - это не реестр российского ПО, вопреки собственному названию.
Приложения, по условиям задачи, изначально "отечественные" и все из себя импортозамещенные. Проблема в том, что Windows-only приложения внезапно могут перестать быть таковыми, независимо от того, кто и где их в действительности делал.
Wine для некоторых разработчиков ПО может оказаться наиболее дешевым и рациональным способом вернуть их детища обратно в реестр кошерных программ.
Подписка здесь должна идти без кавычек, поскольку картриджи, присланные в рамках программы Instant Ink, перестают работать, как только пользователь перестает платить. Из-за чего у пользователей подгорает, т.к. они-то думали, что платили всего лишь за своевременную поставку картриджей, а не за привилегию печатать на собственном принтере.
Это Ваше наоборот очень похоже, наоборот, на "точно также". В НН тоже картой дешевле, чем наличкой, причем сразу на 5 рублей. И отмазка про продажу водителем не проходит - билет (в случае маршруток) покупается всегда у водителя, отличается только способ оплаты и цена.
Защищаются от обратной ситуации (помнится, была некоторое время неопределенная ситуация с тем, будет ли сам Cloudflare блокировать запросы от российских IP); довольно логично, чтобы внешние ссылки российских сайтов на всякие там jQuery и прочие шрифты ссылались не на Google/Azure/Cloudflare, а на гипотетический RusCDN, который не отключит их клиентов по желание своей левой пятки.
Ну и будет меньше некрасивых ситуаций, когда РКН очередной раз блокирует условный GitCloudGoogleHub, а потом у русских потребителей ломаются русские же сайты.
Утверждение "кому надо - купят" не работает для Open Source. Разработчикам, к примеру, медиакомбайнов типа ffmpeg, vlc или gstreamer необходим доступ к десяткам различных стандартов ISO, за доступ к которым им (en masse) никто не заплатит.
Сделка в 2018 году сорвалась в последний момент, потому что США надавили на Голландию. И с тех пор так и идет блокада. Теперь уже США требуют не продавать в Китай оборудование DUV и современные чипы. Почему? Ну вот, как мне видится, одна из предпосылок (из отчета National Security Commission on Artificial Intelligence 2021 года):
Как Америка может обогнать Китай на два поколения? Очевидно, надо а) строить современные фабрики на территории США (привет, Intel), и б) тормознуть сам Китай (привет, санкции).
Что именно должны были сделать КПК, чтобы санкций не было? Да ничего они не могут сделать, если США поставили себе цель "догнать и обогнать", стать глобальными лидерами в производстве современной электроники. Разве что можно перестать быть соперником США и лечь под них, стать ее де-факто колонией, как это произошло с Южной Кореей (зато туда EUV продают без проблем).
Вы не учитываете, что пластину в техпроцессе необходимо экспонировать несколько раз. Для сложной микросхемы типа современного процессора с многими слоями металлизации - вроде бы ~20 раз. Так что 10 литографов при полной загрузке за сутки изготовят 1 (одну) пластину, и ~20 000 эльбрусов.
Опыт Китая с EUV прямщас показывает, что цена может оказаться слишком большой.
Тут скорее не музыкальный инструмент, а программа, которая в несколько кликов создает "произведение" за тебя. Вот только в такого рода программах семплы лицензированы, а контент, который пошел на обучение Midjourney - нет. Так что эта артистка может претендовать на авторство текстового концепта, а вот на авторство картинки скорее могут претендовать сотни художников, чьи картины были использованы как исходные данные.
На мой взгляд, во второй задаче подходит решение "Аристотель - честный безопасный водитель, Мёрдок и Сунь-цзы - лгущие убийцы".
Мёрдок лжет -> Сунь-цзы лжет.
Выбор Сунь-цзы приводит к смерти -> Мёрдок лжет.
Мёрдок убийца, Аристотель говорит правду.
В оригинале "To survive, choose Sun Tzu, or choose Aristotle". Имхо и оригинальное утверждение, и перевод можно понимать как "любой выбор будет безопасен -> ни Сунь-цзы, ни Аристотель не являются убийцами"; по смыслу же приведенного решения похоже, что идея автора была "хотя бы один из двух не является убийцей", из чего делается вывод "Мёрдок лжет -> оба остальные убийцы -> Мёрдок не убийца".
Если посмотреть на даты, то скорее всего у банка вообще не было возможности продлить договор; единственный шанс исправить дело заключался в том, чтобы перестать использовать движок, но на это они пойтить не смогли.
C++ код с классами, конструкторами и деструкторами будет столь же быстрым, как и аналогичный ему C код, но будет более коротким (если код написан правильно, с обработкой ошибок) и читабельным - это если не пользоваться идиоматическими C++ возможностями, а именно виртуальными функциями и исключениями (отключить вообще исключения опциями компилятора).
Если брать более идиоматический код и добавить виртуальные функции, то они будут либо чуть-чуть медленнее, чем применяемые в таких ситуациях C ссылки на функции (если ссылки лежат прямо в структуре - но тогда C-шный вариант будет более прожорлив по памяти), либо такими же по скорости (если C-шный вариант применяет эрзац таблицы виртуальных методов по типу struct ..._ops), либо даже чуть быстрее (32-битный Windows ABI - thiscall более оптимально использует регистры, чем cdecl)
Если добавить исключения как идиоматическую замену кодам ошибок, то код становится еще компактнее и быстрее в "обычном" случае безошибочной работы (т.к. большинство ABI обеспечивают бесплатный try/except, а в C требуется проверка кода ошибки везде). Исключение - тот же 32-битный Windows ABI, где try не бесплатен.
1) CRT - это C runtime library, оно как раз для C.
2) код, написанный на C, обычно без особого геморроя можно скомпилировать C++ компилятором. Вы утверждаете, что код, скомпиленный компилятором C, выполняется быстрее, чем тот же код, скомпиленный компилятором C++?
3) В windows ядро в основном написано на C++. Если говорить про *nix, то системные библиотеки пишут на C потому, что а) у него более стабильный ABI и б) их начали писать 40 лет назад - традиция-с.
Если GPL действительно не совместим с российским законодательством - это отличный повод поправить законодательство :) Хотя если это действительно так, то интересно, как RedHat и Oracle продавали в России свои дистрибутивы.
Для ПО рассматривать импортозамещение исключительно как "написано русскими для русских" - это глупость, синдром NIH национального масштаба. Пусть нам стало недоступно проприетарное ПО зарубежным производителей. Остается доступным огромнейший слой open source, на написание которого были потрачены миллионы человеко-лет; доступно ПО, которое УЖЕ прошло те самые десятилетия развития, на которое уже было потрачено время высококвалифицированных разработчиков, которое уже было отшлифовано миллионами пользователей. И теперь предлагается отбросить все это богатство только на основании того, что его делали не только русские, но и иностранцы?
Импортозамещение - суть обеспечение собственной независимости от иностранного влияния типа санкций. РЕД ОС (Альт/.../подставьте свой любимый Linux) решает эту задачу в нише ОС общего назначения (пусть даже там 99.9% "забугорного" кода) и, увы, альтернативы ему не видно. Никто почему-то пока не написал русскую гениальную ОС, и ждать, пока ее может быть напишут, нельзя.
https://github.com/torvalds/linux/commit/550a7d60bd5e35a56942dba6d8a26752beb26c9f
И использование - https://chromium.googlesource.com/chromium/src/+/refs/heads/main/chromeos/hugepage_text/hugepage_text.cc - выделяют блок hugepage памяти (выровненный по границе большой страницы), копируют данные, задают правильные права, а потом вместо всех телодвижений по переезду - просто делают mremap этого блока по исходному адресу (тоже выровненному по границе большой страницы - это важно). Имеющиеся маппинги автоматически закрываются, hugepages переезжают на новый виртуальный адрес и все.
Случайно наткнулся на патч от Google, где они решали ту же проблему для Chrome; там фиксили mremap с thp. Т.е. может быть в новых версиях Linux можно вместо всей этой чешуйни просто после копирования данных сделать mremap их по оригинальному адресу; но надо смотреть на выравнивание адресов данных.
Еще одна альтернатива была бы вынести весь функционал по переезду данных с page cache на anonymous в отдельный DSO, и тогда не надо было бы городить весь этот изврат с написанием кода, работающего в любом месте в памяти.
Глянул одним глазком на доклад (надо будет посмотреть целиком :)) - действительно, товарищи эту статью видели и им действительно это не подходит; им нужно кровь из носу использовать Transparent Huge Pages, потому они и занимаются нехорошими вещами.
"Нормальному" же пользователю, которому надо сервис почему-либо загнать в HP, будет в 95% случаях проще настроить линукс, как описано в той статье )
Вот тут с идеями об использовании huge pages для кода уже игрался: https://easyperf.net/blog/2022/09/01/Utilizing-Huge-Pages-For-Code
Причем в одном из подходов в huge pages грузится, похоже, код прямо из (специально подготовленного) файла штатно без каких-либо телодвижений. Т.е. " Linux позволит использовать большие страницы только для анонимных отображений в память - то есть, для тех, которые не связаны ни с каким файлом " не вполне верно. На что также намекает строчка
FileHugePagesв /proc/meminfoТаки да - главное это РЕЕСТР. Неважно, что абстрактный 1С:УправлениеВсемИВся или там Компас3D чисто российского производства - без вхождения в реестр российского ПО он не будет считаться таковым. Соответственно его будет трудно продавать. Если минцифры пропишет себе в методички, что ВСЕ российское ПО обязано запускаться на конкретной ОС, то производителю придется как-то выкручиваться. И если у того же абстрактного Компаса под капотом весь UI завязан на DirectX, то Wine может оказаться самым рациональным способом для производителя снова стать "русскими". Wine имхо можно без сильной натяжки отнести к "библиотечному слою" типа JRE/Mono/Gtk+/Qt, которые идут в комплекте с ОС или же с ПО, и не выделяются отдельно.
Windows-под-Linux оставим на совести тех, кто это сделал. А что касается Linux и Wine, то они вполне себе могут быть использованы для импортозамещения - если есть российский разработчик, который легальным образом их поставляет и осуществляет поддержку заказчиков (а это так и есть, соответственно Астра/Базальт/РЕД и Etersoft). Можно, конечно, понимать импортозамещение, как переход на ПО исключительно и полностью российского производства - ОС чисто русской разработки, компиляторы чисто русской разработки, все библиотеки чисто русской разработки, вообще все до последнего бита чисто русское - но это нереалистично и иррационально. Собственно, и "единый реестр российского ПО" - это не реестр российского ПО, вопреки собственному названию.
Приложения, по условиям задачи, изначально "отечественные" и все из себя импортозамещенные. Проблема в том, что Windows-only приложения внезапно могут перестать быть таковыми, независимо от того, кто и где их в действительности делал.
Wine для некоторых разработчиков ПО может оказаться наиболее дешевым и рациональным способом вернуть их детища обратно в реестр кошерных программ.