 | 08.04 | IBM опубликует компилятор COBOL для Linux (217 +30) |
|
Компания IBM объявила о решении 16 апреля опубликовать компилятор языка программирования COBOL для платформы Linux. Компилятор будет поставляться в форме проприетарного продукта. Версия для Linux основана на тех же технологиях, что и продукт Enterprise COBOL для z/OS, и обеспечивает совместимость со всеми актуальными спецификациями, в том числе включает изменения, предложенные в стандарте от 2014 года.
Помимо оптимизирующего компилятора, который можно использовать для сборки имеющихся COBOL-приложений, в состав входит набор runtime-библиотек, необходимый для выполнения программ в Linux. Из особенностей выделяется возможность развёртывания собранных приложений в гибридных облачных окружениях, в которых используются платформы IBM Z (z/OS), IBM Power (AIX) и x86 (Linux). Из поддерживаемых дистрибутивов заявлены RHEL и Ubuntu. По своим возможностям и производительности версия для Linux признана пригодной для разработки критически важных бизнес-приложений. В этом году языку COBOL исполнится 62 года и он остаётся одним из старейших из активно применяемых языков программирования, а также одним из лидеров по объёму написанного кода. По состоянию на 2017 год 43% банковских систем продолжали использовать COBOL. Код на COBOL применяется при обработке около 80% персональных финансовых транзакций и в 95% терминалов для приёма платежей по банковским картам. Общий объём находящегося в обиходе кода оценивается в 220 млрд строк. Благодаря наличию компилятора GnuCOBOL, поддержка языка COBOL на платформе Linux присутствовала и ранее, но не рассматривалось финансовыми учреждениями как решение для промышленного использования.
| ||
|
Обсуждение (217 +30) |
Тип: К сведению |
| ||
 | 08.04 | Обновление свободного антивирусного пакета ClamAV 0.103.2 с устранением уязвимостей (52 +12) |
Сформирован релиз свободного антивирусного пакета ClamAV 0.103.2, в котором устранено несколько уязвимостей:
Из не связанных с безопасностью изменений отмечается перевод в число устаревших настройки SafeBrowsing, которая преобразованы в ничего не выполняющую заглушку в связи с изменением компанией Google условий доступа к API Safe Browsing. В утилите FreshClam улучшена обработка HTTP-кодов 304, 403 и 429, а также возвращён файл mirrors.dat в каталог с БД.
| ||
|
Обсуждение (52 +12) |
Тип: Проблемы безопасности |
| ||
| 07.04 | Rust включён в число основных языков для разработки платформы Android (346 +21) |
|
Компания Google объявила о включении языка программирования Rust в число языков, допустимых для разработки платформы Android. Компилятор языка Rust был включён в дерево исходных текстов Android ещё в 2019 году, но поддержка данного языка оставалась экспериментальной. Одними из первых компонентов на Rust, которые планируется поставлять в Android, являются новые реализации механизма межпроцессного взаимодействия Binder и Bluetooth-стека.
Внедрение Rust произведено в рамках проекта по усилению защищённости, продвижению приёмов безопасного программирования и повышению эффективности выявления проблем при работе с памятью в Android. Отмечается, что около 70% из всех опасных уязвимостей, выявленных в Android, вызваны ошибками при работе с памятью. Применение языка Rust, который сфокусирован на безопасной работе с памятью и обеспечивает автоматическое управление памятью, позволит снизить риск появления уязвимостей, вызванных ошибками при работе с памятью, такими как обращение к области памяти после её освобождения и выход за границы буфера. Безопасная работа с памятью обеспечивается в Rust во время компиляции через проверку ссылок, отслеживание владения объектами и учёт времени жизни объектов (области видимости), а также через оценку корректности доступа к памяти во время выполнения кода. Rust также предоставляет средства для защиты от целочисленных переполнений, требует обязательной инициализации значений переменных перед использованием, лучше обрабатывает ошибки в стандартной библиотеке, применяет концепцию неизменяемости (immutable) ссылок и переменных по умолчанию, предлагает сильную статическую типизацию для минимизации логических ошибок. В Android безопасная работа с памятью обеспечивается в уже поддерживаемых языках Kotlin и Java, но они не подходят для разработки системных компонентов из-за больших накладных расходов. Rust даёт возможность добиться производительности близкой к языкам C и С++, что позволяет использовать его для разработки низкоуровневых частей платформы и компонентов для взаимодействия с оборудованием. Для обеспечения безопасности кода на C и C++ в Android применяется sandbox-изоляция, статический анализ и fuzzing-тестирование. Возможности sandbox-изоляции ограничены и достигли предела своих возможностей (дальнейшее дробление на процессы нецелесообразно с точки зрения потребления ресурсов). Из ограничений применения sandbox упоминаются большие накладные расходы и рост потребления памяти, вызванные необходимостью порождения новых процессов, а также возникновение дополнительных задержек, связанных с использованием IPC. При этом sandbox не устраняет уязвимости в коде, а лишь снижает риски и усложняет проведение атаки, так как для эксплуатации требуется выявление не одной, а нескольких уязвимостей. Методы на основе тестирования кода ограничены тем, что для выявления ошибок необходимо создание условий для проявления проблемы. Охватить все возможные варианты не представляется возможным, поэтому многие ошибки остаются незамеченными. Для системных процессов в Android компания Google придерживается "правила двух", в соответствии с которым любой добавляемый код должен подпадать не больше, чем под два условия из трёх: работа с непроверенными входными данными, использование небезопасного языка программирования (C/C++) и выполнение без жёсткой sandbox-изоляции (наличие повышенных привилегий). Из этого правила следует, что код для обработки внешних данных должен либо быть урезан до минимальных привилегий (изолирован), либо быть написан на безопасном языке программирования. Google не ставит перед собой цель переписать на Rust уже имеющийся код C/C++, а планирует использовать данный язык для разработки нового кода. Использовать Rust для нового кода имеет смысл, так как по статистике большинство ошибок всплывает в новом или недавно изменённом коде. В частности, около 50% выявляемых ошибок работы с памятью в Android выявляются в коде, написанном менее года назад. 
| ||
|
Обсуждение (346 +21) |
Тип: К сведению |
| ||
 | 07.04 | Релиз стратегической игры Warzone 2100 4.0 (39 +46) |
Вышел релиз свободной стратегической (RTS) игры Warzone 2100 4.0.0. Игра изначально разработана компанией Pumpkin Studios и выпущена на рынок в 1999 году. В 2004 году исходные тексты были открыты под лицензией GPLv2 и развитие игры продолжилось силами сообщества. Поддерживается как одиночная игра против ботов, так и проведение сетевых игр. Пакеты подготовлены для Ubuntu, Windows и macOS.
 Краткий список улучшений и изменений в новой версии:
С момента последнего стабильного выпуска было отправлено более 1000 коммитов от многих участников, включая: Alexander Volkov, alfred007 / highlander1599, Bennett Somerville, Björn Ali Göransson, cpdef, Cyp, Daniel Llewellyn, Ilari Tommiska, inodlite, Karamel, KJeff01, lakebeans, Lupus-Mechanicus, Maxim Zhuchkov, Next67, past-due, Paweł Perłakowski, Prot EuPhobos, Solstice245, Thiago Romão Barcala, Tipchik, toilari, Topi Miettinen, TotalCaesar659, Vitya Andreev. Серьёзный вклад в игру также вносит и русскоязычное сообщество, где принимаются к рассмотрению все идеи по улучшению и изменению баланса от фанатов и обычных игроков. У сообщества имеется свой портал с TeamSpeak-ом. Имеется любительская автоматизация по созданию хост-лобби с подсчётом статистики и составлению рейтингов постоянных игроков. Также есть неофициальная, но обширная база карт для игры. Действует Discord сервер для русскоговорящей аудитории.
| ||
| 07.04 | Отчёт о компрометации git-репозитория и базы пользователей проекта PHP (86 +21) |
|
Опубликованы первые результаты разбора инцидента, связанного с выявлением в Git-репозитории проекта PHP двух вредоносных коммитов с бэкдором, активируемым при передаче запроса со специально оформленным заголовком User Agent. В ходе изучения следов деятельности атакующих был сделан вывод, что непосредственно сервер git.php.net, на котором был размещён git-репозиторий не был взломан, но была скомпрометирована база данных с учётными записями разработчиков проекта.
Не исключается, что злоумышленники смогли загрузить базу пользователей, хранившуюся в СУБД на сервере master.php.net. Содержимое master.php.net уже перенесено на новый сервер main.php.net, установленный с нуля. Все пароли разработчиков, использовавшиеся для доступа к инфраструктуре php.net, были сброшены и инициирован процесс их смены через специальную форму восстановления пароля. Репозитории git.php.net и svn.php.net остаются доступны в режиме только для чтения (разработка перенесена на GitHub). После обнаружения первого вредоносного коммита, совершённого через учётную запись Расмуса Лердорфа, основателя PHP, было сделано предположение, что взломан аккаунт Расмуса, и Никита Попов, один из ключевых разработчиков PHP, откатил изменения и блокировал права коммита для проблемной учётной записи. Через какое-то время пришло осознание, что блокировка не имела смысла, так как без верификации коммитов по цифровой подписи, любой участник с доступом к репозиторию php-src мог внести изменение, подставив фиктивное имя автора. Следом атакующие отправили вредоносный коммит от имени самого Никиты. Через анализ логов сервиса gitolite, применяемого для организации доступа к репозиториям, была предпринята попытка определения участника, который действительно внёс изменения. Несмотря на включённый учёт всех коммитов, для двух вредоносных изменений в логе не оказалось записей. Стало ясно, что имеет место компрометация инфраструктуры, так как коммиты добавлены напрямую, в обход подключения через gitolite. Оперативно был отключён сервер git.php.net, а первичный репозиторий переведён на GitHub. Впопыхах было упущено из виду то, что для доступа к репозиторию кроме SSH с использованием gitolite имелся ещё один вход, позволяющий отправлять коммиты через HTTPS. В данном случае для взаимодействия с Git использовался бэкенд git-http-backend, а аутентификация выполнялась при помощи HTTP-сервера Apache2, который проверял полномочия через обращение к базе данных, размещённой в СУБД на сервере master.php.net. Допускался вход не только по ключам, но и по обычному паролю. Разбор логов http-сервера, подтвердил, что вредоносные изменения были добавлены через HTTPS. При изучении логов было выявлено, что атакующие подключились не с первого раза, а вначале пытались подобрать имя учётной записи, но после определения вошли с первой попытки, т.е. они заранее знали пароли Расмуса и Никиты, но не знали их логины. Если атакующие смогли получить доступ к СУБД, то непонятно, почему они сразу не использовали указанный там корректный логин. Данная несостыковка пока не получила достоверного объяснения. Взлом master.php.net рассматривается как наиболее вероятный сценарий, так как на данном сервере был использован очень старый код и устаревшая ОС, которые давно не обновлялись и имели неисправленные уязвимости. Из предпринятых действий отмечается переустановка окружения сервера master.php.net и перевод скриптов на новую версию PHP 8. Код для работы с СУБД переделан для использования параметризованных запросов, усложняющих подстановку SQL-кода. Для хранения хэшей паролей в БД задействован алгоритм bcrypt (ранее пароли хранились с использованием ненадёжного хэша MD5). Существующие пароли сброшены и предложено установить новый пароль через форму восстановления пароля. Так как доступ к репозиториям git.php.net и svn.php.net по HTTPS был привязан к хэшам MD5, решено оставить git.php.net и svn.php.net в режиме только для чтения, а также перенести все остающиеся на них репозитории расширений PECL на GitHub, по аналогии с основным репозиторием PHP.
| ||
|
Обсуждение (86 +21) |
Тип: Проблемы безопасности |
| ||
| 07.04 | В Firefox решено не удалять компактный режим и активировать WebRender для всех Linux-окружений (95 +42) |
|
Разработчики Mozilla решили не удалять компактный режим отображения панелей и продолжить поставку связанной с ним функциональности. При этом видимая пользователям настройка для выбора режима панели (меню "гамбургер" в панели -> Customize -> Density -> Compact или Персонализация -> Значки -> Компактные) будет убрана по умолчанию. Для возвращения настройки в about:config появится параметр "browser.compactmode.show", возвращающий кнопку для активации компактного режима, но с примечанием об отсутствии его официальной поддержки. Для пользователей, у которых включён компактный режим параметр будет активирован автоматически.
Изменение будет реализовано в выпуске Firefox 89, намеченном на 18 мая, в котором также запланировано включение обновлённого оформления, развиваемого в рамках проекта Proton. Напомним, что в компактном режиме используются кнопки меньшего размера и убираются лишние пустоты вокруг элементов панелей и области вкладок для высвобождения дополнительного вертикального пространства для контента. Режим планировалось убрать из-за желания упростить интерфейс и предложить оформление, которое бы подходило большинству пользователей. Дополнительно можно отметить, что в Firefox 88, намеченном на 20 апреля, ожидается активация WebRender для всех пользователей Linux, включая рабочие столы Xfce и KDE, все версии Mesa и системы с драйверами NVIDIA (ранее webRender был включён только для GNOME при наличии драйверов Intel и AMD). WebRender написан на языке Rust и позволяет добиться существенного увеличения скорости отрисовки и снижения нагрузки на CPU за счёт выноса на сторону GPU операций отрисовки содержимого страницы, которые реализованы через выполняемые в GPU шейдеры. Для принудительного включения в about:config следует активировать настройку "gfx.webrender.enabled" или запустить Firefox с выставленной переменной окружения MOZ_WEBRENDER=1.
| ||
|
Обсуждение (95 +42) |
Тип: К сведению |
| ||
| 06.04 | Google опубликовал аудиокодек Lyra для передачи речи при плохом качестве связи (110 +32) |
|
Компания Google представила новый аудиокодек Lyra, оптимизированный для достижения максимального качества передачи речи даже при использовании очень медленных каналов связи. Код реализации Lyra написан на C++ и открыт под лицензией Apache 2.0, но в числе необходимых для работы зависимостей присутствует проприетарная библиотека libsparse_inference.so с реализацией ядра для математических вычислений. Отмечается, что проприетарная библиотека является временной - в дальнейшем Google обещает разработать открытую замену и обеспечить поддержку различных платформ.
По качеству передаваемых голосовых данных на низких скоростях Lyra существенно превосходит традиционные кодеки, в которых используются методы цифровой обработки сигналов. Для достижения высокого качества передачи голоса в условиях ограниченного объёма передаваемой информации, помимо обычных методов сжатия звука и преобразования сигналов, в Lyra применяется речевая модель на базе системы машинного обучения, позволяющая воссоздать недостающую информацию на основе типовых характеристик речи. Задействованная для генерации звука модель обучена с использованием нескольких тысячах часов с записями голосов на более чем 70 языках.  Кодек включает в себя кодировщик и декодировщик. Алгоритм работы кодировщика сводится к извлечению параметров голосовых данных каждые 40 миллисекунд, их сжатию и передаче получателю по сети. Для передачи данных достаточно канала связи со скоростью 3 килобита в секунду. Извлекаемые звуковые параметры включают в себя логарифмические мел-спектрограммы, учитывающие характеристики энергии речи в различных частотных диапазонах и подготовленные с учётом модели человеческого слухового восприятия.  В декодировщике используется генеративная модель, которая на основе переданных звуковых параметров воссоздаёт сигнал с речью. Для снижения сложности вычислений применена лёгкая модель на основе рекурентной нейронной сети, представляющей собой вариант модели синтеза речи WaveRNN, в котором используется более низкая частота выборок, но генерируется параллельно сразу несколько сигналов в разном диапазоне частот. Полученные сигналы затем накладываются для получения единого выходного сигнала, соответствующего заданной частоте дискретизации. Для ускорения также применены специализированные процессорные инструкции, доступные в 64-разрядных процессорах ARM. В итоге, несмотря на применение машинного обучения, кодек Lyra может применяться для кодирования и декодирования речи в реальном режиме времени на смартфонах среднего ценового диапазона, демонстрируя задержку передачи сигнала на уровне 90 миллисекунд.
| ||
|
Обсуждение (110 +32) |
Тип: Программы |
| ||
| 06.04 | KDE neon объявил о прекращении формирования LTS-сборок (126 +11) |
|
Разработчики проекта KDE Neon, формирующего Live-сборки с актуальными версиями программ и компонентов KDE, сообщили о прекращении разработки LTS-редакции KDE neon Plasma, поддержка которой осуществлялась восемнадцать месяцев вместо обычных четырёх. Сборка была рассчитана на повседневное использование людьми, которые хотят получить новые версии приложений, но сохранить стабильный рабочий стол (предлагалась LTS-ветка рабочего стола Plasma, но самые свежие версии приложений).
Прекращение формирование LTS-сборок KDE neon намечено на 1 июля. В качестве причин принятого решения отмечаются огромные затраты на сопровождение, несоответствие общей идее проекта (предоставление самого свежего и современного окружения KDE) и относительно низкая востребованность LTS-сборок у пользователей. Пользователям LTS-ветки KDE neon предложено перейти на обычную редакцию KDE neon User Edition, если стабильность рабочего стола не критична, или на Kubuntu LTS или openSUSE Leap, если у них есть потребность в более стабильном LTS-выпуске KDE Plasma.
| ||
|
Обсуждение (126 +11) |
Тип: К сведению |
| ||
| 06.04 | KDE взял на себя продолжение сопровождения общедоступной ветки Qt 5.15 (90 +33) |
|
В связи с ограничением компанией Qt Company доступа к репозиторию с исходными текстами LTS-ветки Qt 5.15 проект KDE приступил к поставке собственной коллекции патчей Qt5PatchCollection, нацеленной на поддержание на плаву ветки Qt 5 до завершения миграции сообщества на Qt6. KDE взял на себя сопровождение патчей к Qt 5.15, включающих исправления функциональных дефектов, крахов и уязвимостей. Патчи доступны в Git-репозиториях, соответствующих модулям Qt.
В настоящее время коллекция включает только патчи, рецензированные и одобренные проектом Qt, но, в будущем могут быть приняты и патчи, по каким-то причинам не утверждённые в upstream. Критериями включения патчей в коллекцию является важность реализуемого исправления и востребованность в открытом ПО. KDE не планирует выпускать отдельные релизы набора патчей и будет развивать его как непрерывно пополняемую коллекцию, отталкивающуюся от последнего общедоступного среза репозитория Qt 5.15. Приветствуется включение патчей в состав дистрибутивов. Патчи планируется поддерживать до тех пор, пока остаётся потребность пользователей открытых продуктов, завязанных на ветке Qt 5.15, и пока Qt 6 окончательно не вытеснит Qt 5 при разработке открытого ПО. Компания Qt Company, которая намерена способствовать инициативе KDE, выразила понимание, что такому большому проекту как KDE требуется время для перехода на Qt 6. Предоставление исправлений для ветки Qt 5 поможет сделать миграцию более гладкой и даст возможность уделить больше времени стабилизации кода. Напомним, что компания Qt Company с 5 января ограничила доступ к коду с обновлениями для ветки Qt 5.15. Выпущенный в марте корректирующий выпуск 5.15.3, включающий около 250 исправлений, был предоставлен только обладателям коммерческой лицензии. Ограничение введено в соответствии с озвученным год назад планом, подразумевающим общедоступную публикацию кода изменений в LTS-ветках только до формирования очередного значительного выпуска. При этом Qt Company выразила готовность предоставить доступ к закрытым репозиториям сопровождающим внешние Qt-модули. Открытым остался и репозиторий dev-ветки, в которой производится разработка новых выпусков Qt и через которую проходит большинство исправлений для прошлых веток.
| ||
|
Обсуждение (90 +33) |
Тип: Программы |
Интересно
| ||
| 06.04 | Обновление Ruby 3.0.1 с устранением уязвимостей (14 +10) |
Сформированы корректирующие релизы языка программирования Ruby 3.0.1, 2.7.3, 2.6.7 и 2.5.9, в которых устранены две уязвимости:
| ||
|
Обсуждение (14 +10) |
Тип: Проблемы безопасности |
| ||
| 06.04 | Выпуск платформы webOS Open Source Edition 2.10 (53 +11) |
|
Представлен выпуск открытой платформы webOS Open Source Edition 2.10, которая может применяться на различных портативных устройствах, платах и автомобильных информационно-развлекательных системах. В качестве эталонной аппаратной платформы рассматриваются платы Raspberry Pi 4. Платформа развивается в публичном репозитории под лицензией Apache 2.0, а разработку курирует сообщество, придерживаясь совместной модели управления разработкой.
Платформа webOS была изначально разработана компанией Palm в 2008 году и использовалась на смартфонах Palm Pre и Pixie. В результате поглощения компании Palm в 2010 году платформа перешла в руки Hewlett-Packard, после чего HP пыталась использовать данную платформу в своих принтерах, планшетах, ноутбуках и ПК. В 2012 году компания HP анонсировала перевод webOS в независимый открытый проект и в 2013 году начала открытие исходных текстов его компонентов. В 2013 году платформа была выкуплена компанией LG у Hewlett-Packard и теперь применяется на более чем 70 миллионах телевизоров и потребительских устройств LG. В 2018 году был основан проект webOS Open Source Edition, через который компания LG попыталась вернуться к открытой модели разработки, привлечь других участников и расширить спектр поддерживаемых в webOS устройств. Системное окружение webOS формируется с использованием инструментария и базовых пакетов OpenEmbedded, а также сборочной системы и набора метаданных от проекта Yocto. Ключевыми компонентами webOS являются менеджер системы и приложений (SAM, System and Application Manager), отвечающий за выполнение приложений и сервисов, и Luna Surface Manager (LSM), формирующий интерфейс пользователя. Компоненты написаны с использованием фреймворка Qt и браузерного движка Chromium. Отрисовка осуществляется через композитный менеджер, применяющий протокол Wayland. Для разработки пользовательских приложений предлагается использовать web-технологии (CSS, HTML5 и JavaScript) и фреймворк Enact, основанный на React, но возможно и создание программ на С и C++ с интерфейсом на базе Qt. Пользовательская оболочка и встроенные графические приложения в основном реализованы как нативные программы, написанные с использованием технологии QML. По умолчанию предлагается оболочка Home Launcher, оптимизированная для управления с сенсорных экранов и предлагающая концепцию сменяющих друг друга карт (вместо окон).  Для хранения данных в структурированном виде с использованием формата JSON применяется хранилище DB8, использующее в качестве бэкенда БД LevelDB. Для инициализации используется bootd на основе systemd. Для обработки мультимедийного контента предлагаются подсистемы uMediaServer и Media Display Controller (MDC), в качестве звукового сервера применяется PulseAudio. Для автоматического обновления прошивки применяется OSTree и атомарная замена разделов (создаются два системных раздела, один из которых является активным, а второй используется для копирования обновления). Основные изменения в новом выпуске:
| ||
|
Обсуждение (53 +11) |
Тип: Программы |
| ||
 | 05.04 | Перевод на русский язык документации по CPython 3.8.8 (89 +30) |
Леонид Хозяинов подготовил перевод документации по CPython 3.8.8. Опубликованный материал по своей структуре, оформлению и функциональным возможностям стремится к официальной документации docs.python.org. Переведены следующие разделы:
Дополнение: Исходные файлы перевода доступны на GitHub. Для улучшения перевода можно присылать pull-запросы.
| ||
| 05.04 | Google одержал победу в разбирательстве с Oracle, связанном с Java и Android (144 +50) |
|
Верховный суд США вынес решение, касающееся рассмотрения тянущегося с 2010 года судебного разбирательства "Oracle против Google", связанного с использованием Java API в платформе Android. Суд высшей инстанции встал на сторону Google и признал, что использование Java API носит характер добросовестного использования (fair use).
Суд согласился, что целью Google было создание другой системы, ориентированной на решение задач для иного вычислительного окружения (смартфонов), а разработка платформы Android помогла реализовать и популяризировать данную цель. История показывает, что существуют различные пути, в которых повторная реализация интерфейса может способствовать дальнейшему развитию компьютерных программ. Намерения Google были нацелены на достижение подобного творческого прогресса, поддержание которого является основной задачей авторского права. Компания Google заимствовала приблизительно 11500 строк с описанием структур API, что составляет лишь 0.4% от всей реализации API, насчитывающей 2.86 миллиона строк. Принимая во внимание объем и значительность использованной порции кода, 11500 строк были рассмотрены судом как одна небольшая часть значительно большего целого. В составе программного интерфейса скопированные строки неразрывно связаны другим кодом (не принадлежащим Oracle), который используют программисты. Компания Google скопировала рассматриваемую порцию кода не из-за её совершенства или функциональных преимуществ, а так как она давала возможность программистам использовать имеющиеся навыки в новой вычислительной среде для смартфонов. Напомним, что в 2012 году судья, имеющий опыт программирования, согласился с позицией Google и признал, что формирующее API дерево имён является частью структуры команд - набора символов, связанного с определённой функцией. Подобный набор команд трактуется законом об авторском праве как не подпадающий под действие копирайта, так как дублирование структуры команд является непременным условием обеспечения совместимости и переносимости. Поэтому идентичность строк с декларациями и заголовочными описаниями методов не имеет значения - для реализации аналогичной функциональности формирующие API имена функций должны совпадать, даже если сама функциональность реализована по-другому. Так как существует только один способ выражения идеи или функции, то каждый волен использовать идентичные декларации, и никто не может монополизировать такие выражения. Компания Oracle подала апелляцию и добилась в Федеральном апелляционном суде США отмены решения - апелляционный суд признал, что Java API является интеллектуальной собственностью Oracle. После этого компания Google сменила тактику и попыталась доказать, что реализация Java API в платформе Android носит характер добросовестного использования, и данная попытка увенчалась успехом. Позиция Google сводилась к тому, что создание переносимого программного обеспечения не требует получения лицензии на API, а повторение API для создания совместимых функциональных аналогов относится к "добросовестному использованию". По мнению Google, отнесение API к категории интеллектуальной собственности негативно скажется на индустрии, так как подрывает развитие инноваций, а создание совместимых функциональных аналогов программных платформ может стать объектом судебных исков. Компания Oracle второй раз подала апелляцию, и опять дело было пересмотрено в её пользу. Суд постановил, что принцип "добросовестного использования" не применим к Android, так как данная платформа развивается компанией Google с корыстными целями, реализуемыми не через прямую продажу программного продукта, а через контроль над сопутствующими сервисами и рекламой. При этом Google удерживает контроль над пользователями через проприетарный API для взаимодействия со своими сервисами, который запрещено использовать для создания функциональных аналогов, т.е. использование Java API не ограничивается некоммерческим применением. В ответ компания Google подала ходатайство в суд высшей инстанции и Верховный суд США вернулся к рассмотрению вопроса о принадлежности программных интерфейсов (API) к интеллектуальной собственности и вынес окончательное решение в пользу Google.
| ||
|
Обсуждение (144 +50) |
Тип: К сведению |
Интересно
| ||
| 05.04 | Проект Debian начинает голосование по позиции относительно Столлмана (321 +42) |
|
Четвертого апреля была завершена предварительная дискуссия и дан старт голосованию, которое должно определить официальную позицию проекта Debian относительно возвращения Ричарда Столлмана на пост руководителя Free Software Foundation. Голосование продлится две недели, до 17 апреля.
Изначально голосование инициировал сотрудник компании Canonical Стив Лангасек (Steve Langasek), который предложил для ратификации первый вариант заявления (призвать к отставке совета директоров FSF и поддержать открытое письмо против Столлмана). Однако, в соответствии с процедурой публичного обсуждения, представители сообщества Debian предложили альтернативные варианты заявления:
Дополнительно можно отметить, что число подписавших письмо в поддержку Столлмана набрало 5593 подписей, а письмо против Столлмана подписало 3012 человек (кто-то отозвал свою подпись, так как в субботу утром было 3013). 
| ||
| 05.04 | ИСП РАН займётся повышением защиты Linux и поддержанием отечественной ветки ядра Linux (389 +59) |
|
Федеральная служба по техническому и экспортному контролю заключила с Институтом системного программирования Российской академии наук (ИСП РАН) контракт на выполнение работ по созданию технологического центра исследования безопасности операционных систем, созданных на базе ядра Linux. Контракт также подразумевает создание программно-аппаратного комплекса для центра исследования безопасности операционных систем. Сумма контракта - 300 млн рублей. Дата завершения работ - 25 декабря 2023 года.
Среди указанных в техзадании задач:
Цели создания Технологического центра:
| ||
|
Обсуждение (389 +59) |
Тип: Тема для размышления |
| ||
| << Предыдущая страница (позже) | ||
| Следующая страница (раньше) >> | ||
