| · | 07.10 | В GitHub выявлено 543 тысячи оставленных в репозиториях действующих токенов, ключей и паролей (15 +4) |
|
Компания Truffle Security опубликовала результаты анализа утечек учётных данных в репозиториях, размещённых на GitHub. В результате сканирования 224 млн репозиториев, насчитывающих 58 миллиардов файлов, было выявлено 543 тысячи уникальных учётных данных (токенов, ключей и паролей), продолжающих действовать. Действующие учётные данные оставались в репозиториях как минимум год, так как в исследовании использовался срез состояния GitHub от 7 августа прошлого года, а проверка актуальности учётных данных, реализованная через пробные обращения к API, сетевым сервисам и хостам, была выполнена в конце июля нынешнего года.
Медианное время нахождения учётных данных в открытом доступе оценено в 784 дня, при том что самые старые ещё действующие ключи доступа были датированы 2009 годом. Около 200 тысяч найденных действующих учётных данных были помещены в репозитории после включения по умолчанию в GitHub механизма для блокировки утечек конфиденциальных данных и токенов доступа, выполняющего проверку на этапе отправки push-запросов. Утечки не были распознаны из-за размещения в форматах, не поддерживаемых в реализованной защите, при том, что непосредственно включение фильтров примерно в два раза снизило утечки распознаваемых учётных данных. Оказалось, что GitHub успешно выявляет утечки токенов к распространённым сервисам, таким как GitHub, AWS, Slack, SendGrid, Stripe и GCP, но пропускает оставленные в коде параметры подключения к БД, ключи доступа к API Google и закрытые ключи. Параметры подключения к БД и закрытые ключи по умолчанию не блокируются для избежания ложных срабатываний. Ключи доступа к API Google не блокируются, так как имеют префикс AIzaSy, как у открытых ключей Google Maps, предназначенных для интеграции на web-страницы. Что касается найденных учётных данных, которые оказались нерабочими, то большая часть из них относится к токенам доступа и ключам, связанным с сервисами, предоставляющими механизм отзыва. Например, из 101886 NPM-токенов был выявлен только один действующий (0.001%), из 73048 GitHub-токенов - 260 (0.35%), а из 30437 токенов Hugging Face - 15 (0.05%). Для ключей Stripe показатель выживаемости составил 4%, AWS - 8%, GCP - 8%, Slack - 2%, GitLab - 0.64%. Для сравнения из 12985 выявленных параметров подключения к СУБД PostgreSQL активными остались 11465 (88%), из 2421 параметров подключения к MySQL - 1806 (74%), из 126963 сервисных аккаунтов Google Cloud - 69041 (54%), из 3790 токенов к Docker Hub - 1244 (33%), а из 22800 ключей к SendGrid - 9189 (40%). До этого исследователи изучили около 7.5 ПБ данных для обучения AI-моделей, распространяемых через Hugging Face, и выявили в них 221 тысячу действующих учётных данных.
| ||
|
Обсуждение (15 +4) |
Тип: Проблемы безопасности |
| ||
| · | 07.10 | Третий альфа-выпуск мессенджера Pidgin 3 (21) |
|
Представлен третий альфа-выпуск клиента для мгновенного обмена сообщениями Pidgin 3.0 (2.97). Выпуск отмечен как ещё не готовый для повседневного применения. Сборки подготовлены в формате Flatpak и размещены в beta-репозитории на Flathub.
Ветка Pidgin 3 разрабатывается с 2011 года, а до этого ещё три года обсуждалась на уровне концепций и идей. В Pidgin 3 выполнен переход на систему типов GObject, библиотек GTK4 и Adwaita, сборочную систему Meson, GPlugin для обработки плагинов, SQLite для хранения истории чатов и GSettings для работы с настройками. Полностью переработан API. Для определения элементов интерфейса задействован GTK Builder XML, а для отображения истории чатов создана собственная библиотека виджетов Talkatu. В интерфейсе Pidgin 3 объединены в одном окне список контактов и чат. Прекращена поставка консольного клиента Finch (не исключено, что его могут вернуть в будущем). Из протоколов пока развиваются реализации протоколов IRCv3, XMPP, SIP, Demo, Bonjour и Zulip. Ветка Pidgin 3 несовместима с Pidgin 2 и ранее созданными плагинами, но может быть установлена параллельно с имеющимися сборками Pidgin 2. Среди изменений в представленном тестовом выпуске:
| ||
|
Обсуждение (21) |
Тип: Программы |
| ||
| · | 07.10 | Компрометация регистраторов 3 доменных зон позволила получить TLS-сертификаты к сервисам Google (29 +8) |
|
Компания Google сообщила об инциденте, в результате которого атакующим удалось получить TLS-сертификаты для отдельных доменов Google (например, google.as), онлайн-сервисов и крупных компаний в зонах ".gh", ".sl" и ".as". Атака совершена через компрометацию регистраторов национальных доменных зон верхнего уровня - ".gh" (Гана), ".sl" (Сьерра-Леоне) и ".as" (Американское Самоа), что позволило заменить DNS-серверы для доменов в этих зонах и перенаправить запросы на серверы злоумышленников. Перенаправив трафик, атакующие смогли подтвердить владение доменами и получить TLS-сертификаты, так как после изменения данных в DNS проверочные запросы от удостоверяющих центров были отправлены не на реальные, а на подменённые хосты и обработаны на них.
Несанкционированное получение сертификатов было выявлено в результате анализа логов Certificate Transparency, в которых удостоверяющие центры отражают все выданные и отозванные сертификаты. Компания Google заблокировала полученные в ходе атаки нелегитимные сертификаты при помощи механизма CRLSets в браузере Chrome, а также добилась отзыва этих сертификатов удостоверяющими центрами. Пока не раскрывается для каких именно доменов были выпущены обманные сертификаты и какие компании пострадали от атаки. Для минимизации рисков при повторении подобных инцидентов владельцам доменов рекомендовано организовать постоянный мониторинг публичных логов CT (Certificate Transparency) для выявления несанкционированного выпуска сертификатов. В DNS советуют добавить записи CAA (Certification Authority Authorization), определяющие список удостоверяющих центров, которым разрешено выпускать сертификаты для указанного домена. Выставление DNS-записи CAA не защитит от запроса сертификата после подмены DNS, но после возвращения контроля над DNS предотвратит повторный выпуск сертификатов злоумышленниками, используя прокэшированные данные проверки владения доменом.
| ||
|
Обсуждение (29 +8) |
Тип: Проблемы безопасности |
| ||
| · | 06.10 | Опубликованы сборки Raspberry Pi OS для ноутбуков и ПК на базе архитектуры x86_64 (55 +4) |
Проект Raspberry Pi опубликовал новую версию дистрибутива Raspberry Pi OS 2026-10-06 (Raspbian) и объявил о формировании Live-сборки (2.6 ГБ), предназначенной для установки на компьютеры c процессорами на базе архитектуры x86_64. Как и сборки для ARM-плат Raspberry Pi новый вариант построен на пакетной базе Debian 13. Помимо загрузки с USB-носителей версия для ПК включает инсталлятор Calamares, позволяющий установить систему на стационарный жёсткий диск или SSD.
![]() В состав сборки для ПК среди прочего включён сервис Raspberry Pi Connect, предназначенный для удалённого подключения к рабочему столу дистрибутива Raspberry Pi OS через web-браузер. Среда рабочего стола базируется на композитном сервере labwc, использующем библиотеку wlroots от проекта Sway. ![]() Среди изменений в новой версии Raspberry Pi OS: поставка более качественных пиктограмм для меню, появление всплывающих подсказок о сути виджетов и конфигураторе Control Centre, поддержка автомонтирования шифрованных дисков, добавление на панель виджетов для показа заряда аккумуоятора и вызова экранной клавиатуры squeekboard. Также можно отметить общую модернизацию оформления среды рабочего стола и добавление новой dock-панели в дополнение к классической панели задач. Вместо старого меню программ предложены два виджета для запуска приложений - полноэкранный интерфейс навигации по доступным программам c функцией поиска и встраиваемый в панель виджет, сочетающий список открытых окон и область для быстрого запуска приложений. ![]() ![]() Новая dock-панель допускает размещение одновременно со старой панелью задач, например, старая панель может быть закреплена в верхней части окна для отображения индикаторов состояния, а новая dock-панель размещена в нижней части и отвечать за показ списка окон и интерфейса запуска приложений. Состав и размещение панелей настраивается в конфигураторе. ![]()
| ||
|
Обсуждение (55 +4) |
Тип: К сведению |
| ||
| · | 06.10 | Представлена библиотека WinCore для работы Win32-программ в Linux и macOS (75 +14) |
|
Проект WinCore развивает слой совместимости с Win32/WGL, позволяющий компилировать код Windows-программ, написанный на C/C++ с использованием классического API Win32, для запуска в Linux и macOS. WinCore перехватывает классические обработчики Win32 и использует кросс-платформенные бэкенды для отрисовки через SDL3 или SDL2. Код написан на C++ и распространяется под лицензией LGPLv3.
Проект стал результатом переосмысления библиотеки LDL, того же автора, который пришёл к выводу, что вместо проектирования очередного API, логичнее взять проверенный временем процедурный интерфейс Win32 API и сделать его переносимым на разные ОС и устройства. Идея в том, что код пишется по правилам Win32, но нативно компилируется и работает в Windows, Linux и macOS. Библиотека написана на строгом C++98 для максимальной переносимости, но экспортирует чистые заголовочные файлы C89, что гарантирует обратную совместимость и позволяет легко делать биндинги к Rust, Zig, Python и другим языкам через C FFI. На данный момент добавлено 2 бэкенда - SDL2 и SDL3. В будущем планируется добавить бэкенды для XLib и Wayland. Автор не ставит цели, эмулировать все возможности Windows и фокусируется только на подсистемах для мультимедиа и движков. В настоящее время реализовано 5 функций Kernel32.dll (управление модулями, системное время и задержки), 25 функций User32.dll (создание окон, циклы сообщений, позиция курсора и обработка ввода), 5 функций Gdi32.dll (выбор пиксельного формата, вывод битмапов и переключение буферов) и 4 функции Opengl32.dll (создание, удаление и активация контекстов WGL). ![]() ![]()
| ||
| · | 06.10 | Выпуск OpenSSH 10.6 с устранением уязвимостей (65 +15) |
Опубликован выпуск OpenSSH 10.6, открытой реализации клиента и сервера для работы по протоколам SSH 2.0 и SFTP. Устранены проблемы с безопасностью, большинство из которых выявлены при анализе кода с использованием AI-инструментов (CVE-идентификаторы не назначены):
Не связанные с уязвимостями изменения:
| ||
|
Обсуждение (65 +15) |
Тип: Программы |
| ||
| · | 06.10 | 24 октября в Москве пройдёт конференция разработчиков на языке Perl (19 +15) |
|
В субботу 24 октября в Москве состоится ежегодная встреча разработчиков, использующих язык программирования Perl. На конференции будут доклады про разработку GUI на Tcl::Tk, использование Perl в составе AI-оркестратора сервисов агрегации, собственный язык с компилятором и первый тайлинговый оконный менеджер, написанный на Perl. На мероприятии также будет предоставлена возможность обсудить актуальные вопросы, пообщаться вживую и обменяться опытом. Участие бесплатное, но требуется предварительная регистрация. Планируется онлайн-трансляция из зала.
| ||
| · | 06.10 | Опубликован дистрибутив ROSA Fresh 13.3 (64 +15) |
|
Компания НТЦ ИТ РОСА опубликовала дистрибутив ROSA Fresh 13.3, построенный на платформе rosa 13. Дистрибутив распространяется свободно и разрабатывается с участием сообщества. Релиз ориентирован на широкий круг пользователей. Для загрузки доступны сборки с рабочими столами KDE 6 (4 ГБ). KDE 5 (4 ГБ, LXQt (3 ГБ) и GNOME (4 ГБ), а также сборки для серверов (2 ГБ) и виртуальных машин (947 МБ). В репозитории пакеты собраны для архитектур aarch64, e2kv4, i686, loongarch64, riscv64 и x86_64.
Среди изменений:
| ||
| · | 05.10 | Выпуск компоновщика Mold 3.0, развиваемого разработчиком LLVM lld (203 +1) |
|
Опубликован выпуск компоновщика Mold 3.0, который может применяться в качестве более быстрой прозрачной замены GNU linker на Linux-системах. Проект развивает Rui Ueyama, автор компоновщика LLVM lld. Ключевой особенностью Mold является очень высокая скорость связывания объектных файлов, заметно опережающая компоновщики GNU gold и LLVM lld (компоновка в Mold выполняется со скоростью, всего в два раза медленнее простого копирования файлов утилитой cp). Код написан на языке Rust и распространяется под лицензией MIT.
Уменьшение времени на компоновку позволяет значительно повысить удобство разработки больших проектов за счёт сокращения ожидания в процессе формирования исполняемых файлов при отладке и тестирования изменений. Мотивом к созданию Mold стало раздражение от необходимости ждать завершения компоновки после каждого внесения изменения в код, а также низкая эффективность работы существующих компоновщиков на многоядерных системах и желание опробовать принципиально иную архитектуру компоновки, не прибегая при этом к излишне усложнённым моделям, таким как инкрементальная компоновка. Высокая производительность компоновки исполняемого файла из большого числа подготовленных компилятором объектных файлов в Mold достигается использованием более быстрых алгоритмов, активным распараллеливанием операций между доступными ядрам CPU и применением более эффективных структур данных. Например, в Mold реализована техника выполнения интенсивных вычислений одновременно с копированием файлов, упреждающая загрузка объектных файлов в память, использование быстрых хэш-таблиц при разрешении символов, сканирование таблиц перемещений в отдельном потоке и дедупликация повторяющихся в разных файлах объединяемых секций. Ветка Mold 3.0 примечательна переписыванием кодовой базы с C++ (C++20) на язык Rust. Mold 3.0 может использоваться в качестве прозрачной замены Mold 2.42.1, последнего выпуска на языке C++, и поддерживает все ранее доступные опции и целевые архитектуры. Переход на Rust позволил обезопасить проект от потенциальных проблем при обработке повреждённых объектных файлов - в ситуациях, когда версия на С++ аварийно завершалась из-за обращения к областям памяти за пределами буфера, вариант на Rust останавливает работу на этапе проверки границ. Производительность реализации на Rust находится на одном уровне с версией на C++. Помимо миграции на Rust ключевой целью при разработке ветки 3.0 было повышение совместимости с GNU ld и подготовка проекта к возможности использования в качестве компоновщика по умолчанию в дистрибутивах Linux. Сборочная система заменена с CMake на Cargo, а система тестов с ctest на cargo test. Из зависимостей исключена библиотека oneTBB.
| ||
|
Обсуждение (203 +1) |
Тип: Программы |
| ||
| · | 05.10 | Проект PhotoSuite развивает открытый аналог Photoshop (211 +15) ↻ |
|
Доступны первые выпуски графического редактора PhotoSuite, разработчик которого поставил перед собой цель создать продукт, способный заменить классический Adobe Photoshop и полностью поддерживающий форматы PSD и PSB. Программа поддерживает редактирование растровой и векторной графики, и по возможности воспроизводит рабочие процессы, панели инструментов, диалоги, горячие клавиши и модификаторы, привычные пользователям Photoshop CS6. В качестве основного формата файлов применяется PSD. Заявлено, что PSD-файлы, сохранённые в PhotoSuite, могут без проблем открываться в Photoshop и наоборот.
Код написан на JavaScript и распространяется под лицензией GPLv3. Готовые сборки формируются для Linux, Windows и macOS. Для выполнения в качестве обособленного десктоп-приложения задействована небольшая обвязка на языке Rust и платформа Tauri, предоставляющая возможности для использования родных диалогов и меню, доступа к файловой системе, работы с буфером обмена, вывода на печать и перемещения файлов мышью. По заявлению автора проекта, код опубликован после около года разработки в приватном репозитории. В процессе работы используется AI-ассистент, но развивающий проект разработчик не считает PhotoSuite AI-слопом, так полностью контролирует процесс, имея более 20 лет опыта разработки на JavaScript. Среди реализованных возможностей:
![]() ![]() ![]() Дополнение 1: Автор проекта удалил код из репозитория и разместил вместо него сообщение о проведении внутреннего аудита. Код пока остаётся доступен в форках. Также удалён изначальный анонс и все ответы автора на вопросы при обсуждении. Дополнение 2: Код удалён после обвинения в плагиате от разработчика online-редактора изображений Photopea.
| ||
|
Обсуждение (211 +15) ↻ |
Тип: Программы |
| ||
| · | 05.10 | Анонсировано открытие кода браузера Orion для Linux и Windows (72 +22) |
|
Разработчики поисковой системы Kagi объявили о решении открыть исходный код редакций браузера Orion для платформ Linux и Windows. Детали будущей модели развития и лицензии Orion для указанных платформ намерены опубликовать в течение 30 дней. Рассматривается возможность передачи кода на попечение одной из некоммерческих организаций.
Причиной пересмотра политики в отношении публикации кода стало сворачивание разработки Orion для Linux и Windows в пользу развития только версий для macOS и iOS, так как небольшая компания Kagi не смогла потянуть разработку сложного кросс-платформенного продукта и желает больше не распылять ресурсы, а сосредоточиться только на одном варианте браузера. В заявлении указано, что разработчики Orion потратили много времени и сил на создание версий для Linux и Windows, и считают, что проект заслуживает продолжения разработки, но уже без участия Kagi, а силами заинтересованного сообщества. ![]() Браузер Orion построен на движке WebKit и примечателен блокированием по умолчанию рекламы и кода для отслеживания перемещений, отсутствием сбора и отправки телеметрии, интеграцией с поисковыми сервисами Kagi, дополнительными возможностями кастомизации интерфейса и просматриваемых страниц, поддержкой установки дополнений от Safari, Chrome и Firefox. Браузер также демонстрирует более эффективное освобождение памяти - после закрытия вкладок Orion занимает в 3 раза меньше памяти по сравнению с Safari, в 2.5 раза - по сравнению Chrome и в 2 раза - по сравнению Firefox. В Orion можно добавлять в панель собственные кнопки для вызова JavaScript-кода или выполнения доступных в браузере функций. Поддерживается изменение шрифтов, отключение закреплённых (непрокручиваемых) заголовков, принудительное применение тёмного оформления для сайтов, а также выборочное отключение JavaScript, Cookie и внешних шрифтов. Имеется режим быстрого удаления HTML-элементов со страниц через их выделение курсором, а также функция редактирования страницы, позволяющая изменить содержимое перед созданием скриншота или сохранением на диск. Среди других возможностей: вертикальные вкладки, режим быстрого поиска, интеграция с archive.org для просмотра старых версий страниц, режим компактного отображения вкладок, автоскрытие панелей, изменение User Agent, предпросмотр ссылок, группировка вкладок, режим экономии энергии, блокировка автовоспроизведения звука и видео, отключение применяемой на некоторых сайтах блокировки копирования в буфер обмена.
| ||
|
Обсуждение (72 +22) |
Тип: К сведению |
| ||
| · | 05.10 | Инженер из NVIDIA протестировал уровень задержек при использовании Wayland и X.Org (159 +31) |
|
Камиль Лысик (Kamil Łysik), работающий в компании NVIDIA, выступил на конференции XDC 2026 с докладом, в котором рассказал о результатах тестирования задержек вывода информации в окружениях GNOME 49.7 (mutter) и KDE 6.7.4 (kwin) при использовании X.Org Server и Wayland. Задействованный в исследовании код опубликован под лицензией MIT.
В целом выводы сводятся к тому, что различия в отзывчивости не существенны и трудно выделить одного победителя. Наибольшее влияние на задержки, по мнению Камиля, вносят обработка ввода и организация вывода на монитор. Отдельно отмечена технология адаптивного изменения частоты обновления экрана (VRR), включение которой позволило заметно повысить отзывчивость. Также упомянуто решение проблем с задержками, в прошлых тестированиях возникавших при использовании XWayland - в новой кодовой базе XWayland появление дополнительных задержек не зафиксировано. Предложенный метод оценки отзывчивости интерфейса близок к исследованию, проведённому в июле Марком Неттом. Как и в прошлом исследовании для точного измерения времени от нажатия клавиши до изменения информации на экране использовалось специальное аппаратное устройство на базе микроконтроллера ЕSP32-S3, к которому был подключён фотодиод для фиксации изменения яркости точки на экране, и обеспечена симуляция работы USB-клавиатуры. Для вывода были задействованы видеокарта NVIDIA GeForce RTX 5070 и монитор LG 27GN950. В системе применялось ядро Linux 7.1.7 и набор проприетарных драйверов NVIDIA 610.57.04. ![]()
| ||
|
Обсуждение (159 +31) |
Тип: Обобщение |
| ||
| · | 05.10 | Выпуск Phosh 0.58, GNOME-окружения для смартфонов (19 +9) |
Опубликован релиз Phosh 0.58, экранной оболочки для мобильных устройств, основанной на технологиях GNOME и библиотеке GTK. Окружение изначально развивалось компанией Purism в качестве аналога GNOME Shell для смартфона Librem 5, но затем вошло в число неофициальных проектов GNOME и используется в Nura (postmarketOS), Mobian, ALT Mobile, Droidian, некоторых прошивках для устройств Pine64 и редакции Fedora для смартфонов. Phosh использует композитный сервер Phoc, работающий поверх Wayland, а также собственную экранную клавиатуру. Наработки проекта распространяются под лицензией GPLv3+.
![]() Среди изменений:
| ||
|
Обсуждение (19 +9) |
Тип: Программы |
| ||
| · | 05.10 | Тео де Раадт предложил изменения для ограничения доступа к ФС через функцию openat (67 +26) |
|
Тео де Раадт предложил включить в OpenBSD новый механизм для уменьшения поверхности атаки, реализованный через расширение возможностей системного вызова openat. Патчи с реализацией дополнительных флагов для openat и open, ограничивающих возможность перехода к верхним каталогам через "/.." и обращения по абсолютным путям, подготовлены для ядра, libc, а также некоторых приложений из базовой системы. Изменения пока не включены в состав OpenBSD-current и находятся на стадии обсуждения среди разработчиков.
Семейство системных вызовов openat(2) работает как аналог open(2) за исключением того, что если в параметре "path" указан относительный путь, то открываемый файл определяется относительно каталога, связанного с файловым дескриптором "fd", а не относительно текущего рабочего каталога. Если передать в openat абсолютный путь, например:
int dirfd = open("/tmp", O_RDONLY | O_DIRECTORY);
int hfd = openat(dirfd, "/etc/hosts", O_RDONLY);
функция openat() проигнорирует "dirfd" и, как следствие, абсолютный путь обработается обычным образом. Поэтому замена open() на openat() сама по себе не усиливает безопасность программы. Такой вызов может ускорить разбор пути, но не ограничивает доступ к файловой системе. Не гарантируют защиту и флаги, запрещающие абсолютные пути (например, RESOLVE_BENEATH и/или RESOLVE_IN_ROOT для openat2 в Linux): программист должен добавлять их ко всем подходящим вызовам, а при захвате управления процессом атакующий может воспользоваться другими путями открытия файлов. В ходе работы над утилитой openrsync у Тео возникла необходимость ограничить её возможности по обходу файловой системы, но сделать это при помощи функций unveil() и pledge() не представлялось возможным. Тогда возникла идея о механизме, подобном openat(), но со свойствами безопасности, дополняющими pledge/unveil или даже работающими при их отсутствии. Основная идея - сделать ограничения частью самого дескриптора каталога. Для этого предлагается флаг F_BELOW, который можно установить через fcntl(), либо флаг O_BELOW для open(). Ограниченный таким образом дескриптор "dirfd" будет разрешать только переходы вниз по дереву каталогов: вызовы openat() с абсолютным путём или с переходом вверх через ".." будут завершаться ошибкой ENOENT. В случае атаки, приводящей к выполнению кода, таблица файловых дескрипторов процесса будет содержать менее функциональные "dirfd", что будет ограничивать поверхность атаки.
| ||
| · | 04.10 | Проект Rocky Linux анонсировал OpenCourant, форк OpenRadioss (51 +17) |
|
Некоммерческая организация Rocky Enterprise Software Foundation, курирующая разработку дистрибутива Rocky Linux, объявила о создании проекта OpenCourant, который продолжит развитие открытой кодовой базы платформы OpenRadioss после её трансформации в проприетарный продукт. Код проекта продолжит развиваться под лицензией APGLv3 силами сообщества и под управлением некоммерческого фонда, не зависящего от отдельных поставщиков. Для участия в работе над форком приглашаются разработчики, вовлечённые в работу над проектом OpenRadioss до его закрытия.
Код проекта OpenRadioss написан на языке Fortran и был открыт в 2022 году. Несколько дней назад компания Siemens удалила репозиторий OpenRadioss с GitHub, отключила сайт проекта и предложила пользователям перейти на проприетарный продукт Simcenter Radioss. OpenRadioss предназначен для решения задач механики сплошных сред, таких как расчёт прочности инженерных конструкций в высоконелинейных задачах, связанных с большими пластическими деформациями исследуемой среды. Код в основном написан на языке Fortran и поддерживает работу в Linux и Windows. К решаемым проектом задачам относятся проблемы обработки металлов давлением и листовой штамповки, а также симуляция быстропротекающих процессов и механики жидкости и газа.
| ||
|
Обсуждение (51 +17) |
Тип: К сведению |
| ||
| Следующая страница (раньше) >> | ||