Linux / Линукс

Siemens трансформировала OpenRadioss в проприетарный продукт Компания объявила о прекращении разработки OpenRadioss в форме открытого проекта и преобразовала его в проприетарный продукт. Репозиторий OpenRadioss удалён с GitHub, а сайт openradioss.org теперь перенаправляет пользователей на страницу c информацией о закрытии проекта. Предприятиям, заинтересованным в продолжении использования OpenRadioss, предлагается перейти на проприетарный продукт Simcenter Radioss, а для исследователей, учёных и индустриальных партнёров введена в строй программа Simcenter Radioss R&D Program (SCRDP), позволяющая по специальному соглашению получить доступ к коду платформы. Код OpenRadioss был открыт в 2022 году под лицензией AGPLv3 и в течение четырёх лет развивался при участии сообщества как исследовательский проект. Теперь компания Siemens решила создать на основе OpenRadioss профессиональный продукт для инженерных расчётов и 3D-симуляции, инвестировать в его развитие и предоставить полноценную поддержку. После удаления репозитория OpenRadioss в сети остаются форки и архивные копии (1, 2, 3, 4, 5). OpenRadioss предназначен для решения задач механики сплошных сред, таких как расчёт прочности инженерных конструкций в высоконелинейных задачах, связанных с большими пластическими деформациями исследуемой среды. Код в основном написан на языке Fortran и поддерживает работу в Linux и Windows. К решаемым проектом задачам относятся проблемы обработки металлов давлением и листовой штамповки, а также симуляция быстропротекающих процессов и механики жидкости и газа. Linux / Линукс🥸

🍺 Пятничный филологический холивар... Логитеч, Асусь, Гнилобайт и прочие травмы слуха. На днях в комментах под постом про шарики от мышек внезапно вспыхнул классический, покрытый мхом холивар. Я написал "Логитеч", и тут же языковеды в комментах пояснили что "вообще-то Лоджитек!", затем подтянулись эстеты с "всегда был Логитек" 😂 В преддверии пятничного сброса энтропии грех не поковырять эту рану. Давайте расставим точки над Ё. Мы все прекрасно знаем, как это читается в оригинале. Я с эникейской юности уяснил правила игры в нашем с вами АйТи... вся индустрия построена на том, чтобы читать заморские бренды максимально всрато и как написано. Ведь когда мы в девяностых и начале двухтысячных читали названия железок исключительно глазами в прайсах Ultra Electronics и на коробках с радиорынка, рождался тот самый легендарный админский суржик. Это не ошибка, это уже наш культурный код 😊 В итоге родилась целая кунсткамера названий, от которых у современных маркетологов смузи носом идет. Вспомним же классику: 🟢 Logitech (Логитеч / Логитек / Лоджитек). Швейцарцы в 1981 году скрестили французское logiciel (софт) и греческое technologie. По канонам это вообще "ЛожитЭк". Буржуи на презентациях говорят "лОджитек". Но для русского эникея, чистившего спиртом валики в шариковых мышах, это навсегда останется родным и непобедимым Логитечем. И точка. 🟢 Zyxel (Зухель / Зуксель / Зайксел). Главная скрепа эпохи диалапа. Корпоративные мануалы называли контору "Зайксел". Но для миллионов людей, сидевших по ночам в FIDO и державших на тумбочке внешний модем со стрекочущими релюшками, это был, есть и будет "Зухель" (в крайнем случае "Зюксель"). Назови модем Зайкселом на сходке сисопов в 2002 - засмеяли бы всем кабаком. 🟢 Nginx (Энджин-икс / Нгинкс / Энжинкс). Создатель Игорь Сысоев русским языком пояснил, что проект называется "Engine-X", то есть "Энджин-икс". Но в логах и консолях мы читали буквы подряд. В результате родился легендарный мутант Нгинкс\Нджинкс (иногда Энгинкс). 🟢 Palit

Тео де Раадт придумал, как сделать openat() реально безопасным, потому что оказалось, что он таким не был Jказывается, замена open() на openat() сама по себе ничего не дает с точки зрения безопасности. Если передать в openat() абсолютный путь вроде "/etc/hosts", функция просто проигнорирует переданный dirfd и откроет файл как обычно, полностью игнорируя попытку "привязать" доступ к конкретному каталогу. То есть вся эта конструкция с openat(), которую многие программисты годами считали защитным механизмом от directory traversal, на деле защищает ровно ни от чего, если разработчик явно не добавил проверки сам. Де Раадт уперся в эту проблему практически — при разработке openrsync понадобилось жестко ограничить программу от выхода за пределы рабочего каталога, а стандартные unveil() и pledge() для этой задачи не годились. Предложение получилось элегантным: флаг F_BELOW для fcntl() (или O_BELOW для open()), который делает ограничение частью самого файлового дескриптора, а не ответственностью программиста на каждый вызов. Если dirfd помечен таким флагом, любая попытка уйти через ".." или абсолютный путь просто упадет с ENOENT. Разница принципиальная - вместо того, чтобы полагаться на внимательность разработчика, который должен не забыть проверку на каждом из десятков мест в коде, ограничение зашивается прямо в дескриптор на уровне ядра. Отдельно порадовал пассаж про Linux-аналоги RESOLVE_BENEATH и RESOLVE_IN_ROOT для openat2 — де Раадт прямым текстом указал, что эти флаги страдают той же проблемой: их нужно добавлять вручную ко всем нужным вызовам, а в случае захвата процесса атакующий всегда найдет другой способ открыть файл в обход этих проверок. Патчи пока на стадии обсуждения и даже не попали в -current, так что до реального релиза пройдет не один месяц традиционной неспешной процедуры ревью сообщества. Linux / Линукс🥸