/bin/dev - IT Lounge

Теперь бесплатная учётная запись разработчика позволяет легально использовать дистрибутив в продакшене, но не более, чем на 16 машинах и без поддержки. Также RHEL теперь можно легально использовать в публичных облаках, таких как AWS, Google Cloud Platform и Microsoft Azure.

https://www.redhat.com/en/blog/new-year-...ccess-rhel

Пока что спонсируют работу одного разработчика, который будет работать над gccrs в течение следующего года. Рассматривается возможность увеличения штата.

https://opensrcsec.com/open_source_secur...cc_funding

Около 190 пакетов. Опубликовано ядро XNU, части Darwin, компоненты и библиотеки, не связанные с GUI.

https://opensource.apple.com/release/macos-1101.html

На данный момент к LTS-версиям есть доступ только у обладателей коммерческой лицензии. Это связано с выходом Qt 6.0. Все существующие ветки версии 5.15 не будут убираться из свободного доступа, но новые коммиты приниматься не будут. Компания Qt Company готова по отдельному запросу предоставить сопровождающим внешние Qt-модули доступ к закрытым репозиториям, что позволит сообществу возможность наблюдать за изменениями в Qt 5.15. Исправления ошибок и уязвимостей придётся портировать из dev-ветки самостоятельно.

В сообществе уже нашлись те, кто готовы поддерживать собственные LTS-версии, чтобы не зависеть от Qt Company.

https://lists.qt-project.org/pipermail/d...40798.html

Что-то вдруг вспомнил детский стишок, и сразу пришёл в голову интересный юзкейс: А давайте устроим что-то вроде этого, но на тему ОС/дистрибутивов/окружений?

Чтобы не устраивать срач, введём немного правил рекомендаций:

• Сообщения должны содержать описание какой-то фичи, которую Вы считаете важной/интересной/удобной в ОС, дистрибутиве или окружении, котор{ую,ый,ое} Вы используете;
  
• Не стоит вываливать сразу целую кучу, оставьте козырь на следующий раз; ^_~
  
• Можно цитировать чужие описания с дополнением, если Вы считаете это действительно важным;
  
• Сообщения с «Это фигня!» и прочие обсуждения без собственного контента будут удаляться (всё же хочется чтобы этот тред служил некоторого рода референсом для тех кто ищет что-то для себя);
  

Несмотря на все потрясения, для ReactOS это был довольно продуктивный год. Было исправлено много ошибок и нестабильностей, гораздо больше было добавлено. В этом году были наняты на полную ставку два разработчика ядра, это произошло впервые в истории проекта.

В последнее время Shell не привлекает особого внимания, поскольку большая часть работы сосредоточена на ядре, но есть еще некоторые полезные исправления и реализации функций:

• Katayama Hirofumi MZ проделал отличную работу по реализации функции уведомления об изменении файловой системы (также известной как SHChangeNotify) в оболочке. Это требуется для всех приложений, отслеживающих изменения файловой системы.
  
• Визуальные улучшения и улучшения удобства использования: метка «Размер на диске» в диалоговом окне «Свойства файла», клавишные сочетания в диалоговом окне «Открыть»/«Сохранить» и многое другое.
  

He Yang (kernel.bin) продолжает работу, проделанную студентами GSoC в предыдущие годы, улучшая менеджер приложений RAPPS. Это включает в себя улучшения пользовательского интерфейса и удобства использования, отображение снимков экрана приложений и поддержку сценариев командной строки.

Устаревший набор инструментов RosBE 2.1 хорошо справлялся со своими задачами с 2013 года, но пришло время двигаться дальше и включить все полезные функции, реализованные в современных компиляторах и инструментах сборки. Теперь есть GCC 8.4 и CMake 3.17 по умолчанию в новом RosBE 2.2, сохраняя при этом совместимость с последней версией CMake. Однако переход не произошел без нескольких препятствий, Colin Finck приложил немало усилий, чтобы заставить современный CMake работать в Windows Server 2003 (и, следовательно, в ReactOS). Все патчи находятся в свободном доступе на GitHub.

Сборка с помощью Clang теперь возрождена в CI с планами поддержки этого компилятора вместе с GCC и MSVC. ReactOS сейчас собирается с Clang, но все равно не загружается.

Было принято спорное решение отказаться от поддержки старых компиляторов MSVC, и поднять стандарт языка C до C99 для лучшей совместимости кросс-компилятора. Планируемое прекращение поддержки вызвало большую дискуссию в списке рассылки и на GitHub. Тем не менее, это открывает окно для будущих обновлений стандартной библиотеки C ++ (возможно, в 2021 году, кто знает) и поддержки современного C ++ в кодовой базе ReactOS.

Поскольку над ядром на постоянной основе работают два разработчика, есть довольно долгожданные изменения:

Завершён стек хранилища PnP. Новый стек хранилища, созданный на основе драйверов Microsoft с открытым исходным кодом пришел на замену старому NT4-совместимому стеку хранилища ReactOS. В течение долгого времени применялось множество обходных путей, чтобы заставить стек хранения NT4 работать в среде NT5.2. Эта эпоха заканчивается сейчас, когда делается большой шаг вперед в обеспечении совместимости с современной Windows, а также в новых функциях:

• Поддержка таблицы разделов GPT.
  
• Поддержка API пользовательского режима, связанных со стеком хранилища.
  
• Установка и отключение USB-накопителя на ходу.
  
• Специальные команды SSD, диски Blu-ray, диски >2ТБ и многое другое.
  

Поддержка Driver Framework в режиме ядра. Как часть переключателя стека хранилища KMDF был перенесен в ReactOS, что позволило потенциально использовать в ОС больше драйверов. Порт еще не завершен, но уже позволяет использовать некоторые драйверы.

Менеджер памяти/Улучшения подсистем общего кеширования. Этим занимается Jérôme Gardou, параллельно с PnP и хранением от Victor Perevertkin. Эти две подсистемы (CC и MM) бьют рекорды как по количеству затраченного времени, так и по количеству людей, которые над ними работали. Текущие усилия направлены на улучшение совместимости с Windows при запуске драйверов файловой системы. И здесь есть некоторые достижения: ReactOS, наконец, может работать с драйвером ntfs.sys из Windows и может работать с драйвером Microsoft fastfat.sys с открытым исходным кодом для файловой системы FAT. Работы еще не завершены, но обязательно будут в 2021 году.


Улучшения подсистемы Plug and Play. Здесь происходит серьезный рефакторинг, чтобы сделать драйверы более совместимыми и улучшить общую стабильность системы. Теперь стало возможной долгожданная загрузка с USB-носителя в ветке вне дерева (примечание переводчика: это вообще можно было перевести нормально? ☺).

Все эти изменения были бы невозможны без пожертвований сообщества. Большое им спасибо!

Интерпретатор команд ReactOS (CMD) недавно был пересмотрен, с рядом исправлений, направленных на улучшение правил синтаксического анализа командных и пакетных файлов по сравнению с правилами анализа CMD Windows. Эти усилия были вызваны недавним отчетом об ошибке CORE-17030, в котором говорилось о несовместимости нашего CMD для синтаксического анализа команд REM (комментарии, которые игнорируются для целей выполнения командного файла), а также тем фактом, что общий синтаксический анализ команд нашего CMD не полностью совместим с CMD из Windows, согласно свидетельствам многих сбоев, обнаруженных во время тестирования с модульным тестом cmd:batch Wine.


Hermès Bélusca-Maïto решил сделать правила синтаксического анализа CMD ReactOS более совместимыми с правилами Windows, включая некоторые неясные случаи, а также воспользоваться возможностью внести дополнительные исправления в некоторые из своих команд с целью исправления большего количества тестов.

Теперь больше cmd:batch-тестов проходит с меньшим количеством сбоев. Он также добавил новые тесты для парсера CMD в собственный модульный тест cmd:reactos. Большинство из них проходят нормально, за исключением некоторых, для которых все еще требуется дополнительная работа.

Hermès также обнаружил, что некоторые аспекты реализации существующей команды копирования CMD в ReactOS, а также выполнение внешних команд по конвейеру в некоторых случаях действительно не работают. В будущем в этих областях потребуется дополнительная работа.

Старый добрый i386 по-прежнему остается основной платформой, но работа по переносу ReactOS на другие архитектуры постепенно продолжается:

• AMD64: большая часть кода была объединена в master, поэтому теперь ночные сборки могут, наконец, загружаться до первого этапа настройки экрана на некотором оборудовании. Графический интерфейс все еще нуждается в исправлении. Портированием занимается Timo Kreuzer.
  
• XBOX: восстановлен оригинальный порт XBOX для ReactOS, и теперь он может загружаться до рабочего стола. Большую часть работы выполняет Stanislav Motylkov.
  
• PC98: Dmitry Borisov (disean) запустил порт ReactOS для NEC PC-98, который представляет собой версию i386, но с некоторыми несовместимостями.
  

Дальнейшая работа
В настоящее время ведутся работы по нескольким направлениям, которые будут продолжены в 2021 году. Это включает:

• Подсистема прямой совместимости для поддержки приложений Windows Vista и старше.
  
• Поддержка печати.
  
• Улучшения CRT и стандартной библиотеки.
  
• Работа над поддержкой amd64 и APIC HAL (Hardware Abstraction Layer) для поддержки SMP.
  

Наткнулся на вот такой сайт https://abooklikefoo.com/escape/

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

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

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

View this post on Instagram

(Матильда из фильма Леон, продано).

Администрация /bin/dev поздравляет постояльцев и посетителей форума с новым 2021 годом.

Желаем Вам стабильного коннекта и надёжного железа!

Для этого будет использоваться плагин dnf-plugin-cow. Ожидаемое увеличение производительности - на 50%.

https://fedoraproject.org/wiki/Changes/RPMCoW

А может быть кто-то знает, как на POSIX-совместимых операционных системах (ну там BSD, Linux, macOS) происходит различение между файлами и директориями? На Windows директория это файл с атрибутом D.

Я просто пишу один мануал, и там есть вот такое предложение:

Цитата:Directory names can also be referred as file names; directories are nothing more than files with the D attribute.

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