• 2023년 2월 20일
• Ville Voutilainen
• 원문 : https://www.qt.io/blog/qt-is-now-staying-up-to-date-with-new-android-ndk-versions
• 번역 : https://j2doll.tistory.com/730

이 게시물에서는 새로운 Android NDK 버전을 최신 상태로 유지하는 방법과 Qt Creator의 LLDB 지원에 대해 설명합니다. 한동안 우리는 새로운 Android NDK 버전에 대한 지원을 개선해 왔으며 Qt Creator의 디버거 지원이 최신 NDK 버전에서 작동하는지 확인했습니다.

최신 NDK 버전이 Qt 빌드 및 Qt 응용 프로그램 빌드에 대해 잘 작동하도록 처리 시간을 크게 개선했습니다. 이것은 오늘날 우리 프로세스에 포함되는 몇 가지 부분으로 구성됩니다.

1. 우리는 Google의 NDK 릴리스 일정을 추적하면서 향후 NDK 버전 및 해당 릴리스를 미리 계획합니다.

2. Android NDK의 베타 버전을 빌드 테스트하고 컴파일 버그를 조기에 수정합니다.

3. 빌드 수정이 완료되면 새로운 NDK 버전을 계속해서 빌드할 수 있도록 지속적 통합 시스템에 새로운 NDK 버전을 출시합니다.

우리는 한동안 이 작업을 해왔으며 매년 여러 NDK 버전을 추적할 수 있도록 프로세스가 마련되었지만 Google은 이제 NDK 릴리스 주기를 늦추어 새로운 버전을 출시하는 것처럼 보입니다. 1년에 딱 한 번. 그럼에도 불구하고 동일한 방식으로 추적 프로세스를 실행합니다.

Qt 6 또는 이에 대한 애플리케이션이 반짝이는 새 NDK로 빌드되지 않는 경우 버그입니다. 보고해 주세요.

QTBUG-108662가 수정 되었으므로 이제 최신 NDK에서 LLVM 기반 도구 체인을 사용하여 Qt 5 및 애플리케이션 구축을 지원합니다. 버그는 qmake 빌드가 LLVM 도구 체인에서 llvm-ar를 올바르게 사용하는 수정과 함께 ranlib에 대한 나머지 종속성에 관한 것입니다.

Qt 6과 마찬가지로 Qt 5 또는 Qt 5용 애플리케이션이 반짝이는 새 NDK로 빌드되지 않으면 버그입니다. 보고해 주세요.

최신 Qt Creator 버전은 더 이상 GDB를 제공하지 않을 만큼 충분히 새로운 NDK 버전을 선택하는 경우 LLDB를 자동 감지하며, 이를 사용하는 장치에서 디버깅하면 바로 사용할 수 있습니다.

마지막으로 모든 커밋에서 빌드 및 테스트 결과를 확인하는 다른 모든 구성 중에서 Android 12를 CI에 추가하기 위한 마무리 작업을 수행하고 있습니다. 이를 위해 약간의 테스트 사례 조정이 필요했지만 이제 최종 단계에 있으며 곧 병합할 준비가 되었습니다.

• 원문 : https://doc.qt.io/qt-6/portingguide.html
• 번역 : https://j2doll.tistory.com/729

이전 버전인 Qt 5에서 Qt 6으로 Qt에 많은 변경 사항이 있습니다. Qt 6으로 업그레이드 하기 전에 Qt 5 애플리케이션이 Qt 5.15로 업데이트되었는지 확인하십시오. 최신 Qt 5 버전은 Qt 6으로 포팅할 때 변경 사항이 가장 적습니다. 그러나 Qt 5.15에서 더 이상 사용되지 않거나 사용되지 않는 것으로 표시된 API는 Qt 6에서 제거되었을 수 있습니다.

다음은 Qt 5 애플리케이션을 Qt 6으로 포팅하는 경우 확인해야 할 사항입니다.

Qt에서 더 이상 사용되지 않는 API 사용은 일반적으로 컴파일러 경고 형식으로 표시됩니다. 빌드 시스템에서 QT_DISABLE_DEPRECATED_BEFORE C++ 매크로를 정의하여 사용 오류를 만들 수도 있습니다. 5.15 또는 이전 Qt 버전에서 더 이상 사용되지 않는 API를 비활성화하려면 매크로를 0x050F00 16진수로 인코딩된 '5.15.0'으로 정의합니다.

예를 들어 qmake 프로젝트 파일에서 다음을 사용하여 매크로를 정의합니다.

DEFINES += QT_DISABLE_DEPRECATED_BEFORE=0x050F00

CMake에서는 add_compile_definitions를 사용할 수 있습니다.

add_compile_definitions(QT_DISABLE_DEPRECATED_BEFORE=0x050F00)

• Qt 5.15 에서 폐기된 C++ 클래스
• Qt 5.15 에서 사용되지 않는 QML 유형
• Qt 6 에서 폐기된 C++ 클래스
• Qt 6 에서 사용되지 않는 QML 유형

Qt 6 릴리스의 목표는 간소화된 프레임워크를 유지하는 것입니다. 즉, Qt 6에서 일부 Qt 5 모듈을 제거하는 것입니다. 경우에 따라 더 이상 사용되지 않는 모듈의 API를 다른 모듈에서 사용할 수 있습니다. 향후 Qt 6 릴리스에서는 신규 또는 이전 모듈이 추가될 수 있습니다.

• Qt 6.0에서 제거된 모듈
• Qt 6.0의 새로운 모듈
• Qt 6.1의 신규 및 복원 모듈
• Qt 6.2의 신규 및 복원 모듈
• Qt 6의 Qt 모듈에 대한 변경 사항 - Qt 모듈당 변경 사항 목록

QML 응용 프로그램에는 회귀를 테스트해야 하는 새로운 그래픽 백엔드가 있습니다. OpenGL은 대상 플랫폼에서 더 이상 기본값으로 보장되지 않으며 그래픽 코드가 여전히 원하는 것과 동일한 효과를 생성하는지 확인해야 합니다.

Qt 응용 프로그램에서 OpenGL 호출을 계속 사용할 수 있지만 OpenGL API는 Qt OpenGL 모듈로 이동되었습니다. Qt Widgets 응용 프로그램의 그래픽 백엔드는 Qt 5에서 변경되지 않았습니다.

• 그래픽스
• Qt Quick 변경 사항 - Qt 5 응용 프로그램에 영향을 줄 수 있는 Qt Quick 그래픽 변경 사항

Qt 6은 모든 플랫폼에서 높은 DPI 디스플레이를 지원하며 Qt Widgets 또는 Qt Quick과 같은 더 높은 수준의 API를 사용할 때 디스플레이 해상도를 자동으로 고려합니다. 애플리케이션은 이미지 및 아이콘과 같은 고해상도 자산만 제공하면 됩니다. 이 기능은 항상 활성화되어 있습니다.

Qt 6 은 운영 체제 DPI 설정을 정확하게 추적하기 위해 기본 배율 반올림 정책을 Qt::HighDpiScaleFactorRoundingPolicy::Round 에서 Qt::HighDpiScaleFactorRoundingPolicy::PassThrough 로 변경합니다. Qt Widgets를 사용하는 응용 프로그램은 예를 들어 디스플레이가 175%로 구성된 Windows와 같이 정수가 아닌 배율에서 그래픽 결함이 발생할 수 있습니다. 이 경우 반올림 정책을 Round 로 설정하여 Qt 5 동작을 복원하십시오.

자세한 내용은 높은 DPI를 참조하십시오.

Qt 6에서는 대상 플랫폼의 네이티브 API와 더 잘 통합됩니다. 플랫폼 통합 API를 사용하여 Qt에서 제공하지 않는 네이티브 동작을 구현할 수 있습니다. Qt 6의 경우 애플리케이션의 대상 플랫폼에 대한 업데이트가 있는지 확인하십시오.

• 플랫폼 통합
• Qt 플랫폼 추상화
• 지원되는 플랫폼

Clazy 기반 도구를 사용하여 Qt 5에서 Qt 6으로 포팅을 용이하게 할 수 있습니다: Clazy 검사를 사용하여 C++ 애플리케이션을 Qt 6으로 포팅.

• Qt 6의 새로운 기능 - Qt 6 부 버전의 변경 사항
• Qt 6의 빌드 시스템 변경 사항 - 소스에서 Qt 6 빌드용
• CMake: Qt 5 및 Qt 6 호환성 - CMake에서 Qt 5 및 Qt 6을 모두 지원하는 방법

• 2023년 1월 18일
• 피터 슈나이더
• 원본 : https://www.qt.io/blog/c-is-the-programming-language-of-the-year-2022
• 번역 : https://j2doll.tistory.com/727

C++는 선도적인 품질 보증 서비스 제공업체인 Tiobe로부터 2022년 올해의 프로그래밍 언어로 선정되었습니다. C++가 상위 20개 언어 중 가장 빠르게 성장했기 때문에 상을 받았습니다. Qt는 Qt 프레임워크 및 개발 플랫폼을 위한 기본 프로그래밍 언어로서 C++에 대한 장기적인 약속을 확인하므로 이 선택을 환영합니다.

고품질 소프트웨어에 대한 열정을 Qt와 공유하는 Tiobe는, 품질 보증 서비스를 제공하고 있습니다. Tiobe 는 Phillips, Bosch, ST, Huawei 및 ABB와 같은 고객을 위해 매일 10억 라인의 소프트웨어 코드를 테스트합니다. Tiobe는 2003년부터 올해의 프로그래밍 언어로 선정되었습니다.

그렇다면 C++가 다른 코딩 언어보다 인기 있는 이유는 무엇일까요? 티오베는 "C++가 인기를 끄는 이유는 높은 수준의 객체지향 언어이면서 뛰어난 성능 때문"이라고 했으며, "이 때문에 C++로 빠르고 방대한 소프트웨어 시스템(코드 수백만 라인 이상)을 개발할 필요없이 C++로 개발할 수 있고 유지 관리의 악몽으로 끝납니다."고 말했습니다. 또한 Tiobe는 C++11 및 C++20에서 발표된 의미있는 새 기능을 인기 상승의 이유로 언급했습니다. 우리 Qt는 집중력 증가와 같은 다른 요인이 C++로 프로그래밍된 소프트웨어에 대한 에너지 효율 컴퓨팅 및 웹 어셈블리(WASM) 지원으로 인기가 다시 높아졌습니다.

그러나 기업과 개발자가 프로그래밍 언어 포트폴리오에 C++를 추가하도록 동기를 부여하기에 충분한 인기와 빠른 승리일까요? 2022년에 C++가 극적으로 인기를 되찾는 것으로 보는 것은 환상적이지만, 20년 동안 다른 많은 언어를 능가하고 있다는 사실이 더 중요합니다.

디지털 제품을 개발하는 기업은 그러한 제품의 수명 주기가 쉽게 5년 이상이기 때문에 수십 년 동안 프로그래밍 선택을 고수해야 합니다. 새로운 코딩 언어 학습에 투자하는 소프트웨어 개발자는 몇 달이 아닌 몇 년이 아닌 투자 수익을 고려합니다. 따라서 C++가 지난 20년 동안 Tiobe 프로그래밍 커뮤니티 지수에 따라 상위 4개 프로그래밍 언어에 포함된 것을 보는 것은 좋은 일입니다. 명예의 전당에 따르면 C++는 실제로 2003년 최초의 올해의 프로그래밍 언어였습니다.

Tiobe 에 따르면, TIOBE 프로그래밍 커뮤니티 지수는 프로그래밍 언어의 인기도를 나타내는 지표입니다. 인덱스는 한 달에 한 번 업데이트됩니다. 등급은 전 세계의 숙련된 엔지니어 수, 과정 및 타사 공급업체를 기반으로 합니다. Google, Bing, Yahoo!, Wikipedia, Amazon, YouTube, Baidu와 같은 인기 있는 검색 엔진을 사용하여 평점을 계산합니다. TIOBE 인덱스는 최고의 프로그래밍 언어나 대부분의 코드 행이 작성된 언어에 관한 것이 아니라는 점에 유의해야 합니다

C++ 및 Python은 2022년 Tiobe 지수에서 상위 3위 안에 들었습니다. Python은 (언어) 순위의 선두입니다. Qt 프레임워크는 또한 수년 동안 상위 10위권에 있었던 Python을 지원하여 다양성을 높이고 선택한 다중 플랫폼 개발 소프트웨어로 만듭니다 https://www.qt.io/product/supported-platforms-languages?hsLang=en

미래는 이러한 인기의 변화가 C++의 전반적인 성능에 어떤 영향을 미칠지 알려줄 것입니다. Tiobe는 인기의 복귀와 추가 기능을 추정 합니다. (우리) Qt도 그렇게 믿습니다.

C++ 및 Qt 프레임워크를 사용하여 고성능 앱을 만드는 데 관심이 있는 경우 자세한 정보가 있는 웹 페이지를 확인하십시오. https://www.qt.io/product/qt-for-desktop?hsLang=en

• https://j2doll.tistory.com/726

bash

#!/usr/bin/bash

# set environment of QtCreator
export LD_LIBRARY_PATH=/home/user/Qt/Tools/QtCreator/lib/qtcreator:$LD_LIBRARY_PATH
export PATH=/home/user/Qt/Tools/QtCreator/bin:$PATH

# execute QtCreator
cd /home/user/Qt/Tools/QtCreator/bin
./qtcreator

exit

bash

#!/usr/bin/bash

# set Qt environment
export QT_DIR=/home/user/Qt/6.4.1/gcc_64
export QTDIR=$QT_DIR
export PATH=/home/user/Qt/6.4.1/gcc_64/bin:$PATH
export LD_LIBRARY_PATH=/home/user/Qt/6.4.1/gcc_64/lib:$LD_LIBRARY_PATH

# execute bash 
/usr/bin/bash

• Jörg Bornemann 작성
• 2022년 12월 22일
• 원본 : https://www.qt.io/blog/deploying-to-linux-with-cmake
• 번역 : https://j2doll.tistory.com/725

• 얼마 전에 Qt 라이브러리, 플러그인 및 자산을 배포하는 지침으로 단계를 향상할 수 있는 CMake 배포 API 에 대해 블로그에 게시했습니다.
  • cmake --install 작성 당시 Linux는 아직 지원되지 않았습니다.
• 하지만 더 이상은 아닙니다. Qt 6.5는 Linux용 배포 지원을 제공합니다!

• 간단한 Qt 응용 프로그램을 배포하는 방법을 빠르게 요약합니다.

• 다음 프로젝트를 고려하십시오.

• cmake

    cmake_minimum_required(VERSION 3.22)
    project(MyApp)
    
    find_package(Qt6 REQUIRED COMPONENTS Widgets)
    qt_standard_project_setup()
    
    qt_add_executable(MyApp main.cpp)
    target_link_libraries(MyApp PRIVATE Qt::Widgets)
  

• 이제 애플리케이션을 설치하고 설치 단계를 개선합니다.

• 우리의 목표는 설치 후 (대부분) 독립된 디렉토리를 갖는 것입니다.

• cmake

    # Install the executable into "${CMAKE_INSTALL_PREFIX}/bin".
    install(TARGETS MyApp
        BUNDLE  DESTINATION .
        RUNTIME DESTINATION ${CMAKE_INSTALL_BINDIR}
    )
    
    # Generate the deployment script for the target MyApp.
    qt_generate_deploy_app_script(
        TARGET MyApp
        FILENAME_VARIABLE deploy_script
        NO_UNSUPPORTED_PLATFORM_ERROR
    )
    
    # Call the deployment script on "cmake --install".
    install(SCRIPT ${deploy_script})
  

• 프로젝트를 빌드하고 설치합니다.

• sh

    $ qt-cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/tmp/my-application ..
    [output omitted]
    
    $ cmake --build .
    [output omitted]
    
    $ cmake --install .
    -- Install configuration: "Release"
    -- Installing: /tmp/my-application/bin/myapp
    -- Set runtime path of "/tmp/my-application/bin/myapp" to "$ORIGIN:$ORIGIN/../lib"
    -- Writing /tmp/my-application/bin/qt.conf
    -- Running generic Qt deploy tool on /home/someone/playground/myapp/build/myapp
    -- Installing: /tmp/my-application/lib/libQt6Core.so.6
    -- Installing: /tmp/my-application/lib/libQt6Core.so.6.6.0
    -- Installing: /tmp/my-application/lib/libQt6DBus.so.6
    -- Installing: /tmp/my-application/lib/libQt6DBus.so.6.6.0
    -- Installing: /tmp/my-application/lib/libQt6EglFSDeviceIntegration.so.6
    -- Installing: /tmp/my-application/lib/libQt6EglFSDeviceIntegration.so.6.6.0
    -- Installing: /tmp/my-application/lib/libQt6EglFsKmsSupport.so.6
    -- Installing: /tmp/my-application/lib/libQt6EglFsKmsSupport.so.6.6.0
    -- Installing: /tmp/my-application/lib/libQt6Gui.so.6
    -- Installing: /tmp/my-application/lib/libQt6Gui.so.6.6.0
    -- Installing: /tmp/my-application/lib/libQt6OpenGL.so.6
    -- Installing: /tmp/my-application/lib/libQt6OpenGL.so.6.6.0
    -- Installing: /tmp/my-application/lib/libQt6Widgets.so.6
    -- Installing: /tmp/my-application/lib/libQt6Widgets.so.6.6.0
    -- Installing: /tmp/my-application/lib/libQt6XcbQpa.so.6
    -- Installing: /tmp/my-application/lib/libQt6XcbQpa.so.6.6.0
    -- Installing: /tmp/my-application/plugins/egldeviceintegrations/libqeglfs-emu-integrat...
    -- Installing: /tmp/my-application/plugins/egldeviceintegrations/libqeglfs-kms-egldevic...
    -- Installing: /tmp/my-application/plugins/egldeviceintegrations/libqeglfs-x11-integrat...
    -- Installing: /tmp/my-application/plugins/imageformats/libqgif.so
    -- Installing: /tmp/my-application/plugins/imageformats/libqico.so
    -- Installing: /tmp/my-application/plugins/imageformats/libqjpeg.so
    -- Installing: /tmp/my-application/plugins/xcbglintegrations/libqxcb-egl-integration.so
    -- Installing: /tmp/my-application/plugins/xcbglintegrations/libqxcb-glx-integration.so
    -- Installing: /tmp/my-application/plugins/platforms/libqxcb.so
  

• myapp 실행 파일이 /tmp/my-application/bin/ 에 설치된 후, 배포 스크립트는 다음 작업을 처리합니다.

• qt.conf 디렉터리 레이아웃에 대한 정보가 포함된 실행 파일 옆에 파일을 만듭니다.

  • 이것은 플러그인과 자산을 찾기 위해 런타임에 필요합니다.
  • 자세한 내용은 qt.conf 설명서 를 참조하십시오.

• CMake의 내장 파일(GET_RUNTIME_DEPENDENCIES) 로 실행 가능하고 사용된 Qt 플러그인을 검사 하여 배포할 Qt 라이브러리를 결정합니다.

• 필요한 Qt 플러그인과 Qt 라이브러리를 설치합니다.

• 이제 설치 디렉토리를 다른 시스템에 복사할 수 있으며 응용 프로그램은 계속 작동합니다.

• 설치 후에는 패키지와 배송이 가능한 멋진 독립형 디렉토리가 있습니다.
  • 예를 들어, cpack을 사용하여 .deb 패키지를 만들겠습니다.

• 프로젝트 파일 끝에 다음을 추가합니다.

• cmake

    set(CPACK_PACKAGE_NAME my-app)
    set(CPACK_PACKAGE_DESCRIPTION_SUMMARY "My amazing application")
    set(CPACK_PACKAGE_VENDOR "My Company")
    set(CPACK_PACKAGE_INSTALL_DIRECTORY ${CPACK_PACKAGE_NAME})
    set(CPACK_VERBATIM_VARIABLES ON)
    set(CPACK_PACKAGING_INSTALL_PREFIX "/opt/myapp")
    set(CPACK_DEBIAN_PACKAGE_MAINTAINER "Manfred Maintainer <mm@example.com>")
    set(CPACK_DEBIAN_PACKAGE_DEPENDS libc6 libstdc++6 libgcc-s1)
    include(CPack)
  

• 프로젝트를 재구성하고 cpack을 실행합니다.

• sh

    $ cpack -G DEB
    CPack: Create package using DEB
    CPack: Install projects
    CPack: - Install project: MyApp []
    CPack: Create package
    CPack: - package: /home/someone/projects/myapp/build/my_app-1.0-Linux.deb generated.
  

• 그게 답니다. 패키지가 포장되어 배송될 준비가 되었습니다.

• 패키지 내용을 다음과 같이 검사할 수 있습니다.
  • dpkg -c my_app-1.0-Linux.deb
• 그리고 설치하기
  • sudo dpkg -i my_app-1.0-Linux.deb.

• 우리는 Qt 6.5의 CMake 배포 API를 사용하여 Linux에 간단한 Qt 애플리케이션을 배포하는 방법을 살펴보았습니다.
  • 전용 linuxdeployqt 도구가 없습니다.
  • 현재 솔루션은 전적으로 CMake의 내장 기능에 의존합니다.

• 다음은 Qt의 CMake 배포 API에서 다루는 플랫폼입니다.
  • 윈도우
  • 맥 OS
  • 리눅스

• Android 및 iOS의 경우 androiddeployqt/macdeployqt를 수동으로 호출하거나 Qt Creator가 이러한 세부 정보를 처리하도록 해야 합니다.

• 재배치 가능한 설치 폴더는 cpack와 같은 도구를 사용하여 패키지로 편리하게 래핑할 수 있습니다.

• 발견한 문제를 버그 추적기 에서 보고해 주세요. https://bugreports.qt.io/

• 도움이 되셨으면 하단의 ❤️ 공감 버튼 부탁 드립니다. 감사합니다! 😄
• 일부 모바일 환경에서는 ❤️ 버튼이 보이지 않습니다.

• Andy Shaw 작성
• 2022년 9월 12일
• 원문 : https://www.qt.io/blog/security-advisory-zlib-in-qt
• 번역 : https://j2doll.tistory.com/723

1.2.12 버전까지의 zlib에는 큰 gzip 헤더 추가 필드를 통해 inflate.c의 inflate에 힙 기반 버퍼 읽기 또는 버퍼 오버플로가 있으며 CVE ID CVE-2022-37434가 할당되었습니다.

이것은 inflateGetHeader를 직접 호출하는 응용 프로그램에만 영향을 미치므로 Qt를 사용하는 응용 프로그램은 이것의 직접적인 영향을 받지 않습니다. 이 기호는 다른 취약점과 함께 사용되거나 응용 프로그램이 이 기능을 직접 사용하는 경우 여전히 악용될 수 있습니다.

솔루션: 다음 패치(Gerrit에서 2개 또는 다운로드 가능한 단일 패치)를 적용하거나 Qt 6.4.0, Qt 6.3.2, Qt 6.2.6 또는 Qt 5.15.11로 업데이트하십시오.

• Patches:
  • dev:
    • https://codereview.qt-project.org/c/qt/qtbase/+/429597
    • https://codereview.qt-project.org/c/qt/qtbase/+/430422
  • Qt 6.4
    • https://codereview.qt-project.org/c/qt/qtbase/+/429655
    • https://codereview.qt-project.org/c/qt/qtbase/+/430870
  • Qt 6.3
    • https://codereview.qt-project.org/c/qt/qtbase/+/429654
    • https://codereview.qt-project.org/c/qt/qtbase/+/430919
    • https://download.qt.io/official_releases/qt/6.3/CVE-2022-37434-qtbase-6.3.patch
  • Qt 6.2
    • https://codereview.qt-project.org/c/qt/tqtc-qtbase/+/429679
    • https://codereview.qt-project.org/c/qt%2Ftqtc-qtbase/+/430921
    • https://download.qt.io/official_releases/qt/6.2/CVE-2022-37434-qtbase-6.2.patch
  • Qt 5.15
    • https://codereview.qt-project.org/c/qt%2Ftqtc-qtbase/+/429680
    • https://codereview.qt-project.org/c/qt%2Ftqtc-qtbase/+/430922
    • https://download.qt.io/official_releases/qt/5.15/CVE-2022-37434-qtbase-5.15.patch

• 원문 : https://www.qt.io/blog/scalability-to-the-max
• 번역 : https://j2doll.tistory.com/718
• 작성 : Peter Schneider 2022년 6월 9일

장치 포트폴리오를 비용 효율적으로 개발하는 것은 어려울 수 있습니다. 모든 하드웨어 기술에 대해 하나의 개발 도구만 필요할 때 도움이 됩니다.

2011년, 저는 MeeGo 라는 운영 체제를 실행하는 Nokia N9 스마트폰 을 만들 때 Nokia의 제품 관리 부서에서 일했습니다 . 스마트폰과 태블릿을 위한 Linux 기반 운영 체제인 MeeGo 운영 체제를 개발할 때 우리는 확장성에 대해 끊임없이 생각했습니다. 보급형 스마트폰에서 고성능 태블릿으로 확장하려면 OS가 필요했습니다. MeeGo OS는 하이엔드 Intel에서 로우엔드 ARM CPU 기술에 이르기까지 무엇이든 실행해야 했습니다. UI는 작은 스마트폰 해상도에서 태블릿 크기 장치로 확장되어야 했습니다.

우리는 다양한 디스플레이 크기에 맞게 확장할 수 있도록 MeeGo OS와 애플리케이션을 설계하고 개발했습니다. 하지만 당시에는 다양한 칩셋 기술을 위한 다양한 하드웨어 적응 및 펌웨어를 사내에서 구축해야 했습니다. 광범위한 제품 포트폴리오를 유지하기 위한 값비싼 하드웨어 적응은 노키아가 스마트폰 사업과 함께 마지막 몇 년 동안 직면한 많은 과제 중 하나였습니다.

Wikipedia의 기고자에 따르면 Nokia는 코드명 Meltemi 를 사용하여 프로젝트에서 가격을 낮추기 위해 Meego 스마트폰 포트폴리오를 확장하려고 시도했습니다.. Meltemi 프로젝트의 목표는 "경계선 로우엔드 스마트폰용으로 설계된" MeeGo OS의 가벼운 파생물이어야 했습니다. 스마트폰과 같은 경험을 제공하는 피처폰용 MeeGo OS의 파생물을 구축한다는 것은 낮은 CPU 및 메모리 제약 조건에 적응하도록 UI 프레임워크와 OS 미들웨어를 간소화하는 것을 의미했을 것입니다. 덜 강력한 하드웨어에서 풍부한 스마트폰 OS와 유사한 경험을 모두 갖는다는 것은 Meltemi 프로젝트에서 일부 MeeGo OS 구성요소의 간소화된 버전을 유지하는 것을 의미했을 것입니다. 불행히도 MeeGo OS는 Windows Phone OS로의 플랫폼 전략 변경으로 인해 잠재력을 발휘할 기회가 없었습니다. 또한 Wikipedia에 따르면 Meltemi 프로젝트는 2012년에 중단되었습니다.

요즘에는 디스플레이가 있는 연결된 장치 포트폴리오를 개발하는 것이 마술처럼 보일 필요가 없습니다. 펌웨어 강화와 같은 과제는 여전히 모든 임베디드 장치 개발자의 마음에 있지만 오늘날에는 상황이 조금 더 쉽습니다. Qt는 저가형 마이크로 컨트롤러 장치(MCU)에서 마이크로 처리 장치(MPU)가 있는 고급 칩셋에 이르기까지 통합 소프트웨어 개발 플랫폼 및 참조 하드웨어 적응을 제공합니다. Qt는 2019년 말에 MCU 구동 장치용 개발 툴킷을 출시했습니다. MCU용 Qt 툴킷을 사용하면 기업이 통합 소프트웨어 개발 플랫폼 기능의 이점을 누릴 수 있습니다.

이미지: Qt Creator IDE와 같은 MCU 툴킷 자산용 Qt

프런트 엔드 개발자는 Figma 또는 Adobe XD에서 UI 디자인을 가져와 MCU 와 MPU 에서 실행되는 기능적인 UI 코드 로 변환할 수 있습니다 . 풀스택 개발자는 Qt Creator IDE의 UI에 애플리케이션 로직을 추가할 수 있습니다. 간소화된 즉시 사용 가능한 UI 컨트롤은 개발 프로세스를 가속화합니다. 참조 장치 이미지는 대상 장치의 첫 번째 부팅 속도를 높입니다. 2022 년 2월부터 고객 은 더 이상 MCU 개발 툴킷을 활용하기 위해 전용 라이선스가 필요하지 않습니다.. MCU 및 MPU 기반 장치 개발을 위한 모든 Qt 기능은 모든 Qt Device Creation 라이선스 패키지에서 사용할 수 있습니다.

전반적으로 Qt for MCU 기능은 전용 소프트웨어 라이브러리에 번들로 제공되는 Qt 프레임워크의 UI 인에이블러의 간소화된 버전입니다. 가벼운 그래픽 엔진이 스마트폰과 같은 부드러운 사용자 경험을 제공합니다. 그런 다음 전체 응용 프로그램을 다양한 방식으로 컴파일하여 사용 가능한 처리, 캐싱 및 메모리 구성에 대한 성능을 최적화할 수 있습니다. 이러한 기능은 초기에 별도로 라이선스가 부여되었지만 MCU용 Qt는 이제 동일한 라이선스로 모든 하드웨어 장치 개발자가 사용할 수 있습니다.

MeeGo OS는 MCU 진화를 위한 Qt와 직접적인 관련이 없는 제 경력의 이야기지만, 회사가 포트폴리오의 다양한 가격대에서 균질한 고객 경험을 효과적으로 구축하기 위해 다양한 접근 방식을 시도했음을 보여줍니다. Qt for MCU는 MPU에서 MCU 구동 장치로 고객 경험을 확장하는 Qt의 입증된 방법입니다. Qt for MCU 기술은 현재 릴리스 2.1이며 많은 고객이 성공적으로 채택했습니다. Qt for MCU에 대해 더 알고 싶으시면 Qt for MCU 웹페이지 를 확인하세요 . 이미 Qt for Device Creation 라이선스가 있는 고객이라면 기존 Qt 기반 사용자 인터페이스를 즉시 재사용 하고 MCU 기반 장치에서 더 낮은 가격대와 더 많은 제품 볼륨으로 확장할 수 있습니다.

• Qt 상용 라이선스 라이센스 License 간소화! (2022년 2월) https://j2doll.tistory.com/704
• 최대 확장성 – 동일한 라이선스로 MCU 및 MPU 개발 (2022년 6월) https://j2doll.tistory.com/718
• Qt 그룹, 라이선스 계약 업데이트 출시 (2024년 2월) https://j2doll.tistory.com/1035
• Qt 라이선스 및 구성 요소별 적용: 상업용, LGPL, GPL 차이점과 선택 가이드 (2024년) https://j2doll.tistory.com/823

• 원문 : https://www.qt.io/blog/commercial-add-on-qt-vnc-server
• 번역 : https://j2doll.tistory.com/717
• 작성 : Eskil Abrahamsen Blomfeldt, 2022년 7월 6일

"VNC"(또는 가상 네트워크 컴퓨팅 ) 호환성은 Qt에서 오랜 역사를 가지고 있으며 이제 Qt 6.4와 호환되는 상용 애드온으로 이 이야기를 개선하고 있습니다.

Qt의 역사에서 저는 고고학적 발굴을 했고, 제가 찾을 수 있었던 VNC 지원에 대한 첫 번째 언급은 2000년 7월 5일부터 "VNC 원격 프레임 버퍼 지원"이라는 변경 사항에서 임베디드 Linux(Qt 2.2일 가능성이 높음)로의 매우 초기 포트에서였습니다. 그러나 기술적으로 말하면 VNC는 브랜드 이름이며 지원되는 프로토콜은 "RFB"(Remote FrameBuffer)라고 합니다. 이 프로토콜을 사용하는 클라이언트와 서버를 일반적으로 "VNC 호환"이라고 합니다.

https://datatracker.ietf.org/doc/html/rfc6143

이 원래 지원은 시간이 지남에 따라 소위 "Lighthouse 프로젝트"의 일부로 Qt 4 기능 릴리스 중 하나에 제공된 현재 구현으로 발전했으며 나중에 QPA(Qt Platform Abstraction)로 브랜드가 변경 되었습니다.

따라서 Qt 4, 5 및 6에서 VNC에 대한 기존 지원은 헤드리스 모드에서 애플리케이션을 실행하고 연결할 때 원격 VNC 호환 클라이언트에 렌더링할 수 있는 플랫폼 플러그인입니다. 모든 Qt GUI 기반 응용 프로그램은 "-platform vnc" 를 명령줄 옵션으로 전달하거나 환경에서 QT_QPA_PLATFORM=vnc 를 설정하여 이 모드에서 실행할 수 있습니다. (참고: 이 플러그인은 현재 Linux 플랫폼에서만 빌드됨)

이것은 매우 우아하고 오늘날까지 원활하게 작동하지만 한 가지 단점이 있습니다. 로컬 디스플레이에 원격 디스플레이로 동시에 렌더링할 수 있는 유일한 방법은 VNC 호환 클라이언트를 서버와 함께 로컬로 실행하고 이를 localhost 에 연결하는 것입니다. 이 때문에 여러 고객이 로컬 디스플레이에 미러링을 포함하도록 기능을 확장해 달라는 요청을 받았습니다. 일반적으로 사용 사례는 사용자가 요청 시 원격 사용자에게 디스플레이를 브로드캐스트하려는 임베디드 장치(종종 Qt Wayland Compositor 의 지원)입니다.

https://doc.qt.io/qt-6/qtwaylandcompositor-index.html

예를 들어, 원격 사용자는 효율적으로 돕기 위해 최종 사용자가 화면에서 보고 있는 것을 정확히 확인해야 하는 지원 담당자가 될 수 있습니다. 응용 프로그램은 기본적으로 방해 없이 실행되어야 하지만 요청 시 원격 사용자와 내용을 공유하고 원격 입력(선택 사항)을 수락할 수 있어야 합니다. Qt의 VNC QPA 플러그인은 이 사용 사례를 다루지 않습니다. 원격 연결이 가능하려면 애플리케이션을 닫았다가 다시 시작해야 하고 최종 사용자는 시스템이 이 모드에서 실행 중입니다.

그래서 우리는 이에 대한 솔루션을 제공하기 시작했고 Qt VNC 서버 모듈을 생각해 냈습니다. 이것은 Qt 6.4와 호환되는 기술 미리보기로 상용 고객에게 제공됩니다. 문서 스냅샷은 여기에서 볼 수 있습니다 .

https://doc-snapshots.qt.io/qtvncserver/index.html

이 작업에 들어갈 때 우리의 주요 사용 사례는 Qt Wayland Compositor 기반 디스플레이 서버에서 원격 데스크톱을 지원하는 것이었지만 Wayland에 대한 지원을 제한하는 것이 합리적이지 않다는 것을 빨리 깨달았습니다.

Qt Wayland Compositor는 일반적으로 다른 클라이언트의 그래픽 버퍼를 구성하는 Qt Quick 응용 프로그램이므로 Qt Quick 응용 프로그램의 콘텐츠를 공유할 수 있는 모든 솔루션은 합성기에서도 작동합니다. 또한 일부 고객은 시스템에 여러 디스플레이를 가지고 있으며 원격 사용자가 RFB 연결을 통해 이러한 디스플레이 중 하나만 볼 수 있도록 제한할 수 있다는 것도 알고 있었습니다.

그래서 우리가 완성한 솔루션을 사용하면 VNC 호환 클라이언트와 모든 Qt Quick 응용 프로그램 또는 그 일부를 공유할 수 있습니다. 그리고 일반적으로 Qt Quick과 마찬가지로 우리는 솔루션을 가능한 한 사용하기 쉽게 만들려고 노력했지만 여전히 많은 사용 사례를 다룰 수 있을 만큼 충분히 강력합니다.

제품에서 Qt VNC 서버를 사용하려면 QtVncServer 모듈을 가져오고 원격으로 공유하려는 하위 트리의 루트로 VncItem 을 생성하기만 하면 됩니다. 활성 연결이 없는 경우 이는 빈 Item 처럼 작동 하며 애플리케이션에 눈에 띄는 오버헤드를 일으키지 않습니다.

사용자가 연결할 때 ShaderEffectSource 와 동일한 메커니즘을 사용 하여 하위 트리의 내용을 캡처하고 이를 원격 클라이언트와 공유합니다. 명시적으로 비활성화하지 않는 한 클라이언트의 입력을 추가로 수락합니다.

Qt VNC 서버의 예 중 하나는 이것이 Qt Wayland Compositor와 어떻게 작동하는지 보여줍니다.

여기에서 Qt Wayland Compositor 내에서 실행되는 3개의 Qt 애플리케이션을 볼 수 있으며 전체 데스크탑이 VNC를 통해 공유되고 있습니다. 원격 사용자가 데스크톱을 원격 제어하면서 Wiggly 앱에 입력했습니다. (이것은 주요 사용 사례 중 하나일 수 있지만 Qt VNC 서버 모듈 자체는 크로스 플랫폼이며 Wayland에 대한 종속성이 없다는 점을 언급할 가치가 있습니다.)

Qt의 기존 VNC 플러그인은 계속 사용할 수 있으며 아무데도 가지 않지만 Qt VNC 서버는 기본적으로 사용 가능한 원격 데스크톱 솔루션이 없을 수 있는 자체 플랫폼을 구축하는 사용자에게 가치를 추가하기를 바랍니다.

QPA 플러그인의 지원과 일치하는 RFB 프로토콜에 대한 기본 지원 외에도 Qt VNC 서버는 Hextile 압축 및 Zlib 압축(libz를 사용할 수 있는 경우)도 구현합니다. 네트워크 연결을 통해 너무 많은 데이터를 전송하지 않도록 손상 영역 감지를 지원합니다. 그리고 마지막으로 libtomcrypt 라이브러리(사용 가능한 경우)를 통해 DEC 인증을 사용한 암호 보호를 지원합니다.

Qt VNC 서버는 현재 기술 프리뷰로 간주됩니다. 이것은 우리가 잠재 사용자로부터 피드백을 찾고 있음을 의미합니다. 추가 기능이 필요합니까? API가 원하는 대로 작동합니까, 아니면 조정해야 합니까? 등.

이는 또한 모듈의 향후 릴리스와의 호환성 보장이 없지만 API가 상당히 작기 때문에 변경 사항을 따라가는 것이 너무 비실용적이지 않아야 함을 의미합니다.

Qt 상용 고객인 경우 Qt 유지 관리 도구를 통해 Qt VNC 서버를 다운로드할 수 있습니다. 앱으로 테스트를 실행하고 귀하의 생각을 알려주십시오 . 제안 및 버그는 평소와 같이 Qt 지원을 통해 보고할 수 있습니다.

• 작성자: Peter Schneider
• 작성일: 2022년 5월 10일
• 원문: https://www.qt.io/blog/is-open-source-really-free
• 번역: https://j2doll.tistory.com/715

기성 소프트웨어를 사용하면 개발 속도가 빨라집니다. 그러나 오픈 소스 소프트웨어(OSS)의 사용은 무료가 아닙니다. 오픈 소스를 사용하는 것은 비용을 수반하는 의무와 위험을 수반합니다.

이 가이드는 공개 정보와 나의 15년 경험을 기반으로 전문 소프트웨어 개발을 위해 오픈 소스 소프트웨어를 사용하는 비용을 요약합니다.

배경: 저는 오픈 소스 원칙에 기반한 많은 소프트웨어를 사용해 왔습니다. 저는 Nokia Networks의 캐리어급 블레이드 서버용으로 Solaris OS에서 JBoss OS(Red Hat이 인수하기 전)로 전환했습니다. Nokia에서 저는 모바일 장치용 오픈 소스 운영 체제인 maemo.org를 홍보하고 기여했습니다. 저는 엔터프라이즈 서비스 관리 플랫폼의 제품 관리를 이끌 때 Angular, Docker, Log4J 및 Fullcalendar.io와 같은 많은 오픈 소스 라이브러리를 사용해 왔습니다.

작성자 참고: 저는 오픈 소스 소프트웨어의 가치를 굳게 믿습니다. 오픈 소스 사용 비용을 분석하는 것은 오픈 소스 소프트웨어의 가치를 높이거나 무시하기 위한 수단이 아닙니다. 저는 항상 공통의 이익이 있을 때 지적 재산을 공유하는 것이 소프트웨어 개발의 미래라고 믿어왔습니다. 그럼에도 불구하고 나는 항상 오픈 소스 사용에 대한 대가를 기꺼이 지불할 용의가 있었다. 그것이 JBoss에 대한 지원 비용이든, Maemo 커뮤니티 의 후원이든, 서비스 관리 플랫폼 에서 수년간의 오픈 소스 관리 비용을 지불 하든, 또는 오픈 소스 제품과 연결된 프리미엄 기능 획득( fullcalendar.io ).저는 항상 특히 상용 제품 개발에서 오픈 소스 소프트웨어를 중요하게 여겼습니다. 이 가이드의 목적은 더 나은 결정을 위한 투명성을 제공하는 것입니다.

오픈 소스 소프트웨어의 취득 비용은 거의 0에 가깝습니다. 그러나 오픈 소스 소프트웨어에는 관리 비용과 위험이 따릅니다. 아래 그림은 오픈 소스 소프트웨어 기반 개발과 관련된 총 소유 비용에 대한 일반적인 오해를 보여줍니다.

오픈 소스 소프트웨어 라이브러리를 사용할 때 첫인상에는 총 소프트웨어 개발 비용이 직원 및 개발 도구에 대한 직접 개발 비용으로만 구성됩니다. 상업적으로 지원되는 소프트웨어 라이브러리에는 소프트웨어 라이선스 및 잠재적인 배포 로열티에 대한 추가 요금이 부과됩니다. 이 비교를 보면 어떤 접근 방식을 선택할지 결정하는 것이 간단해 보입니다. 그러나 모든 진실은 표면 아래에 있습니다.

상용 소프트웨어의 사용에는 제품 수명 동안 숨겨진 비용이 거의 포함되지 않지만 오픈 소스 라이브러리를 사용할 때는 몇 가지 추가 비용을 고려해야 합니다. 여기에는 다음이 포함됩니다.

1. 상업적 유지 관리자가 사용자를 대신하여 버그를 수정하는 대신 직접 수정 합니다. (또는 커뮤니티의 누군가가 무료로 빠르게 수정해주기를 바랍니다)

2. 감사를 위해 사용된 오픈 소스 구성 요소 문서화, 사람들이 소스 코드를 다운로드할 수 있는 저장소 관리, 제품에 사용된 오픈 소스 라이브러리를 표시하는 사용자 인터페이스 생성과 같은 오픈 소스 의무 구현

3. 새로운 오픈 소스 요소를 도입하거나 오픈 소스 라이선스 조건이 변경된 경우 법적 확인 및 위험 평가 구현

4. 기업 정보 보안, 기업 오픈소스 정책, 오픈소스 라이선스 조건에 따른 정기 라이선스 준수 점검 수행

이 가이드에서는 연간 보안 감사 및 간접 일회성 비용과 같은 기타 직접 비용을 제외했습니다. 두 경우 모두 침투 테스트를 포함한 보안 감사를 수행해야 합니다. 공개적 명예훼손으로 인한 제품 유통권 상실, 특허 소송, 브랜드 훼손 등 오픈 소스 약관 위반과 관련된 일회성 비용이 워낙 커서 제외했습니다. 이것들은 위험으로 간주되어야 합니다.

가이드는 예제를 기반으로 오픈 소스의 총 비용을 보여주는 형식으로 작성되었습니다. 입력 값으로 TCO 계산을 쉽게 조정할 수 있습니다. 이 가이드의 초점은 개별 결과가 아니라 비용 구성 요소를 설명하는 데 있습니다.

버그 수정에는 시간이 걸립니다. 오픈 소스를 사용하든 사용하지 않든 모든 소프트웨어에는 버그가 있습니다. 문제는 버그를 수정한 사람일 뿐입니다. 상업적으로 지원되는 소프트웨어 라이브러리를 구입하면 코드 관리자가 버그 수정을 수행합니다. 오픈 소스를 사용하는 경우 다른 사람이 오픈 소스 커뮤니티에서 버그를 수정하기를 바랄 수 있습니다. 그러나 오픈 소스 커뮤니티에는 SLA(서비스 수준 계약)가 없습니다. 또는 오픈 소스의 버그를 스스로 수정하고 오픈 소스 유지 관리자에게 업스트림 코드 라이브러리, 즉 코드 마스터의 버그 수정을 병합하도록 요청할 수 있습니다. 이러한 물류 또한 추가 노력이며 오픈 소스 프로젝트 관리자가 승인할 것이라는 보장이 없습니다. 오픈 소스 프로젝트가 자체 제작한 버그 수정을 수락하지 않으면 모든 새 버전으로 오픈 소스 라이브러리를 수동으로 패치해야 합니다.

버그 수정 노력을 계산하기 위해 모든 소프트웨어 코드에서 찾을 것으로 예상되는 평균 버그 양으로 버그를 수정하는 데 걸리는 평균 시간을 추정할 수 있습니다. 인터넷을 검색하면 상용 제품의 버그를 수정하는 데 소프트웨어 개발자의 평균 반나절에서 하루가 걸린다는 진술을 여러 개 찾을 수 있습니다. 20명의 개발자로 구성된 R&D 팀을 운영한 경험에 따르면 하루 만에 버그가 수정되는 것을 본 적이 없습니다. 코드를 실제로 수정하는 데 30분이 채 걸리지 않는다는 데 동의하지만 버그를 수정하는 데 걸리는 시간은 극히 일부에 불과합니다. 버그를 수정하는 데 걸리는 개발자 일의 범위를 0.5일에서 2일로 설정합니다.

개발자가 소프트웨어 버그를 수정하는 데 0.5 ~ 2일이 걸립니다.

비용 계산을 위한 두 번째 매개변수는 오픈 소스 소프트웨어의 버그 수입니다. 오픈 소스 소프트웨어의 수명 주기 동안 다른 소프트웨어만큼 많은 버그가 있다고 가정합니다. 이 경우 우리는 널리 사용되는 가정을 사용합니다. Carnegie Mellon University의 CyLab Sustainable Computing Consortium 에 따르면 상용 소프트웨어에는 일반적으로 코드 1000줄당 20~30개의 버그가 있습니다. 오픈 소스 소프트웨어가 개별적으로 개발된 소프트웨어보다 버그가 더 적 다고 가정해 봅시다 (더 많은 참가자가 동일한 소프트웨어에 기여하고 사용하기 때문에). 그러면 우리는 그 스펙트럼의 하단에서 가치를 취할 수 있습니다.

오픈 소스 소프트웨어에는 코드 1000 줄 당 평균 20개의 버그가 있습니다.

이는 애플리케이션에 몇 줄의 코드가 있고 그 중 얼마나 오픈 소스인지에 대한 질문을 남깁니다. 앱에는 다양한 코드 라인이 있습니다. 평균적인 iPhone 앱은 50,000줄 , Über 앱은 428,000줄, TikTok은 1,500만 줄의 코드를 가지고 있습니다. 이 복잡성을 단순화하기 위해 그리고 저는 Qt에서 일하기 때문에 우리 모델 애플리케이션이 이중 라이선스(상업적으로 지원되고 오픈 소스)에서 사용 가능한 Qt Framework Essential 오픈 소스 라이브러리를 사용한다고 가정합니다. Qt Framework Essentials 소프트웨어 라이브러리는 고성능 모바일 앱, 데스크탑 애플리케이션 및 임베디드 장치에서 자주 사용됩니다. Qt 6.3 릴리스의 Qt Framework Essentials(qtbase 및 qtdeclarative 리포지토리)에는 SLOCCount가 있는 측정값에 따라 2.936.523줄의 코드(LOC)가 포함되어 있습니다.

Qt Framework Essentials 라이브러리에는 약 3백만 줄의 코드가 포함되어 있습니다.

마지막으로 소프트웨어 개발자의 하루 평균 비용을 추정해야 합니다. glassdoor.com을 기준으로 2022년 미국 소프트웨어 개발자의 평균 급여를 555 USD/day로 사용하겠습니다. 간접 직원 비용에 1.25 승수를 추가하면(EU 자금 지원 프로그램에 사용된 것과 동일한 비율 사용) 평균 소프트웨어 개발자 하루에 688 USD 비용이 발생합니다. 예상되는 버그의 수를 소프트웨어가 리팩토링되거나 다시 실행되는 일반적인 기간인 10년 동안 배포할 것입니다. 따라서 Qt Framework Essentials 오픈 소스 라이브러리를 자체적으로 유지 관리한다면 다음을 의미합니다.

  3,000,000 LOC
/ 10 년
x 20 버그
/ 1,000 LOC
x 0.5 일
x 688 USD
-------------------
2,064,000 USD
 (26억 3261만 1,360 원, 1 USD = 1260 KRW, 2022년 5월)

오픈 소스 커뮤니티에서 대부분의 버그를 수정할 것으로 예상할 수 있지만 전체 버그 중 1% 만 수정하면 된다고 가정하더라도 여전히 매년 20,640 USD 의 비용이 듭니다.

오픈 소스 소프트웨어의 사용에는 의무적 의무와 자발적 의무가 모두 따릅니다. 의무적 책임의 범위는 코드에 부여된 라이선스 조건의 유형에 따라 다릅니다. GPL, MIT 및 BSD와 같은 약어 뒤에 숨어 있는 다양한 오픈 소스 라이선스 유형이 있지만 오픈 소스 소프트웨어 사용자의 일반적인 책임은 다음과 같습니다.

i. 어떤 오픈 소스 소프트웨어가 활용되었는지 표시하는 사용자 인터페이스(UI)를 제품에 개발해야 합니다. 여러 오픈 소스 소프트웨어로 소프트웨어를 만들면 이 UI를 개발하는 노력이 각 오픈 소스 구성 요소 간에 공유됩니다.

일반적으로 더 많은 오픈 소스를 사용할수록 모든 콘텐츠를 통합하는 데 더 많은 시간이 필요합니다. 소프트웨어 제품에서 이 UI의 초기 개발은 내가 참여한 두 번의 백로그 개선 회의를 기반으로 5-10 개발자 일(DEVELOPER DAY)이 소요됩니다. 콘텐츠의 유지 관리에는 1년에 하루 개발자가 소요될 것으로 예상합니다.

ii. 제품과 함께 또는 별도로 소스 코드를 사용할 수 있도록 해야 합니다. 즉, 오픈 소스 라이선스에 따라 때로는 자신의 코드도 사람들이 오픈 소스 코드를 검사하고 다운로드할 수 있는 저장소를 관리해야 합니다. 사람들이 오픈 소스 소프트웨어를 요청하고, 관련 소스 코드를 사용할 수 있는 소프트웨어 저장소를 생성 및 유지 관리하고, 이에 대한 책임을 지는 사람을 지정할 수 있는 워크플로를 만드는 것이 가장 좋습니다.

해당 UI의 개발은 개발자 2~3일 정도 소요됩니다. 워크플로를 설정하는 데 개발자 2일이 더 걸립니다. 소프트웨어 리포지토리를 만들고 유지 관리하려면 Github와 같은 기존 인프라를 사용하여 하루가 필요할 수 있습니다.

iii. 특히 비즈니스 소프트웨어를 구축하는 경우 고객이나 잠재 고객의 잠재적인 요청에 대한 모든 오픈 소스 소프트웨어 라이선스와 라이선스 조건을 나열하는 내부 문서를 관리하려고 합니다. 이 문서를 유지 관리하는 것은 로켓 과학이 아니지만 처음에는 개발자의 하루를 만들고 이 목록을 관리하기 위해 매년 다른 하루를 따로 둡니다(UI에 게시된 것과 동일한 원시 형식일 수 있음).

iv. 제품 사용자는 장치에서 오픈 소스 라이브러리를 수정할 수 있어야 합니다. 하드웨어 제품을 구축하는 경우 장치 소프트웨어를 플래시하는 수단을 제공해야 합니다. 어쨌든 서비스 목적으로 깜박이는 인터페이스가 필요할 수 있지만 문서를 포함하여 사용자를 위한 도구 체인을 제공하려면 상당한 노력이 필요할 수 있습니다. 도구 체인을 만들고 유지 관리하는 데 5일의 개발자 일을 할당할 것이지만 그 숫자는 적어도 초기에는 작업을 완료하기에는 너무 적습니다.

의무적 책임 비용을 합산하면 다음 비용이 발생합니다.

일회성 비용:

   5 개발자 일 (OSS 목록 UI)
+  2 개발자 일 (OSS 요청 UI)
+  2 개발자 일 (OSS 요청 워크플로)
+  1 개발자 일 (소프트웨어 저장소)
+ .1 개발자 일 (OSS PDF 문서)
+  5 개발자 일 (소프트웨어 플래싱 툴체인)
-----------------------------------------
  16 일
x 688 USD (개발자 일일 요금)
---------------------------------------
 11,008 USD (1,403만 1,016원, 2022년 5월)

연간 비용:

    1 개발자 일 (OSS UI 업데이트)
+ 0,5 개발자 일 (OSS 저장소 업데이트)        
+ 0,5 개발자 일 (OSS 요청 처리)
+ 0,5 개발자 일 (OSS PDF 유지 관리)
-------------------------------------------
  2.5 개발자 일
x 688 USD(개발자 일일 요금)
------------------------------------------
  1,720 USD (219만 3,189원, 2022년 5월)

오픈 소스 커뮤니티에 대한 자발적인 활동에는 버그 수정 기여, 원본 코드에 대한 기능 향상 공유, 오픈 소스 커뮤니티 이벤트 참여 및 후원, 오픈 소스 승인자 또는 유지 관리자와 같은보다 적극적인 역할 수행이 포함됩니다. - 소스 구성 요소. 자원봉사 활동과 관련된 비용은 모두가 선택할 수 있으므로 이 안내서에는 포함하지 않겠습니다. 그러나 오픈 소스 커뮤니티는 사회의 한 형태이며 대부분의 후원자가 프로젝트에 다시 기여할 때만 작동한다는 점을 기억하는 것이 좋습니다.

대부분의 회사는 새로운 오픈 소스 소프트웨어가 제품에 추가될 때마다 법적 확인을 실행합니다. 법적 평가는 주로 현재의 오픈 소스 정책을 준수하는지 확인하는 역할을 합니다. 오픈 소스 라이선스 유형은 한정되어 있기 때문에 이러한 법적 확인에는 많은 시간이 걸리지 않습니다. 오픈 소스 라이선스 정책의 변경이 필요한 경우 이러한 법적 확인에는 상당한 시간이 소요됩니다. 그런 변호사들이 게이트키퍼 역할을 하는 경우가 많으며, 관련 비용은 주로 한 번만 발생한다.

제 생각에 변호사는 위험 관리, 사용자에 대한 다운스트림 규정 준수, 다른 당사자가 소유한 산업 특허 및 IPR 준수, 자체 IPR 보호에 관한 오픈 소스 라이선스 사용을 지속적으로 모니터링해야 합니다. 이러한 활동 중 일부는 쉽게 수량화할 수 없으며 일부는 전체 비즈니스를 위태롭게 하는 위험을 초래할 수 있습니다.

하지만 대부분의 기업은 현실이 다르고 법적 점검은 단 한 번만 이뤄진다. 온라인으로 라이선스 조건을 확인하고 위험을 감수할 가치가 있는지에 대한 조사를 수행하는 법적 확인은 하루 이상 걸리지 않을 수 있습니다. 이러한 확인 중 하나는 매년 수행해야 할 것으로 예상됩니다.

  1 선임 변호사 일 (SENIOR ATTORNEY DAY)
x 1,038 USD
--------------------------------
  1,038 USD (132만 3,564원, 2022년 5월)

Glassdoor.com에 따르면 미국 선임 변호사의 평균 연봉: 148.000 USD. 간접 비용: 207.000 USD, 일일 요금: 1.038 USD

규정 준수 관리에는 다음을 확인하는 기업의 모든 활동이 포함됩니다.

• 회사의 제품에는 내부 IPR 및 오픈 소스 정책에 따라 오픈 소스 소프트웨어만 포함됩니다.
• 회사는 오픈 소스 의무를 준수합니다.

Synopsys 의 2019년 백서에 따르면 감사 대상 코드베이스의 85% 에 라이선스 준수 문제가 포함되어 있습니다. 오픈 소스 정책의 명확성과 소프트웨어 개발자 교육을 통해 사전에 준수를 달성하는 것이 바람직합니다. 앞서 언급한 법적 확인도 준수 달성의 일부입니다. 또한 많은 회사에서 자동 소프트웨어 스캔 및 라이선스 관리 도구와 같은 개발 후 규정 준수 방식을 적용하고 있습니다.

Snyk 또는 Debricked와 같은 자동화된 소프트웨어 스캐닝 제품은 개발자당 가격이 책정되는 클라우드 솔루션인 경우가 많습니다. 개발자당 가격은 월 25달러에서 139달러 사이입니다(적어도 공개적으로 볼 수 있는 가격일 경우). 5명의 소프트웨어 개발자에게 이 기능에 대한 라이선스가 필요하다고 가정하겠습니다. 이러한 제품은 GPL3 라이선스 코드와 같은 회사 정책을 준수하지 않을 수 있는 오픈 소스 소프트웨어가 제품에 포함되어 있는지 확인하는 데 도움이 됩니다. 오늘날 애플리케이션에는 수백만 줄의 코드가 포함되어 있으므로 자동화된 스캔은 규정 준수 문제를 방지하는 효과적인 방법이 될 수 있습니다.

  5 소프트웨어 개발자 기여 (CONTRIBUTING SOFTWARE DEVELOPERS)
x 25 USD / 월
x 12 개월
-----------------------------------------------
  1,500 USD (191만 2,665원, 2022년 5월)

오픈 소스 소프트웨어의 총 소유 비용(TCO)은 자동차 구입에 비유할 수 있습니다. 자동차에는 특정 구입 비용이 있습니다. 그러나 자동차 대리점에 지불하는 가격 외에도 등록, 보험 및 지원 비용과 같은 추가 비용을 고려해야 합니다. 오픈 소스 소프트웨어의 구입 비용은 0 이지만 제품 수명 기간 동안 알아야 할 다른 비용이 있습니다.

이 가이드에서는 상용 소프트웨어 수명의 최소값일 수 있는 5년 기간의 TCO를 계산합니다. TCO를 초기 비용과 연간 반복 비용으로 나눕니다. 앞서 말씀드린 것처럼 소송비나 사회공헌비 등 가능성이 희박하거나 자발적인 비용은 제외하도록 하겠습니다.

일회성 비용:

오픈 소스 의무: (16 DEV DAYS x 688 USD) = 11,008 USD (1,403 만 1,016원, 2022년 5월)

연간 비용:

버그 수정(3M LOC / 20 BUG / LOC / 10년 x 0,5 DEV DAYS x 688 USD x 소유 1%) = 20,640 USD (2,630만 5,680원, 2022년 5월)

오픈 소스 의무: (2,5 DEV DAYS x 688 USD) = 1,720 USD (21만 9,318원, 2022년 5월)

법적 수표: (변호사 1일 x 1.038 USD) = 1,038 USD

규정 준수 검사(5 DEVS x 25 USD/월 X 12 개월): 1,500 USD
----------------------------------------------------------
   24,898 USD (3,173만 6,733원)
x  5년
----------------------------------------------------------
 124,490 USD (1억 5,868만 3,668원)
+ 11,008 USD (오픈 소스 의무)
----------------------------------------------------------
 135,498 USD (1억 7,276만 5,369원, 2022년 5월)

크게 보면 135,000 USD는 소프트웨어 제품을 개발할 때 그리 많지 않습니다. 오픈 소스 비용에 대한 대안은 상업적으로 지원되는 소프트웨어 비용으로, 종종 SaaS 구독 모델로 제공됩니다.

의도적으로 저는 오픈 소스 또는 상용 소프트웨어 중에서 어느 쪽으로 갈 것인지 신중하게 권고했습니다. 결정은 항상 많은 요인에 따라 달라집니다. TCO도 그 중 하나입니다. 개인적으로 저는 Qt Company에서 일하기 때문에 편향되어 있습니다. 두 가지를 모두 수행하는 것이 좋습니다. 즉, 오픈 소스를 기반으로 하는 상업적으로 지원되는 소프트웨어를 사용하고 오픈 소스 프로젝트에 업스트림에 기여하는 것입니다. 왜요? 오픈 소스의 취득 비용은 매우 매력적이며 관련 비용의 많은 부분을 여러 오픈 소스 구성 요소에서 공유할 수 있지만, 고객의 주요 고객이 에스컬레이션하여 해결하기 어렵다고 생각하는 하나의 중요한 버그만 있으면 됩니다. 당신을 지지해 줄 누군가가 있는 것을 좋아했습니다. 오픈 소스의 이점과 이에 대한 기여는 소프트웨어의 더 나은 품질에 있습니다. 따라서 내가 추천하는 것은 커뮤니티에서 활동하는 것입니다.

이 가이드가 유용했습니까? Qt Company에서 의뢰한 Forrester 의 Smarter Products Need Smarter Development 가이드 와 같은 소프트웨어 개발에 대한 Qt 가이드를 확인하십시오.

• 작성 : Iikka Eklund
• 일자 : 2022년 4월 20일
• 원본 : https://www.qt.io/blog/qt-6.2.4-packages-for-the-conan-package-manager
• 번역 : https://j2doll.tistory.com/714

Qt 6.2.4 Conan Technology Preview 패키지는 이제 Conan 서버 의 Conan 패키지 관리자 를 통해 사용할 수 있습니다. 데스크톱 패키지는 Windows(MSVC2019 및 MinGW), macOS 및 Linux에서 사용할 수 있습니다.

Conan은 C/C++용 네이티브 바이너리를 생성하고 공유하는 오픈 소스, 탈중앙화, 다중 플랫폼 패키지 관리자입니다. 우리의 장기적인 목표는 Conan을 통해 "패키지 관리자 방식으로" Qt 모듈 설치 및/또는 구축을 지원하는 것이었습니다.

• 필요한 것을 정확히 소비/다운로드 합니다. Qt Conan 패키지는 모듈화되어 프로젝트에 실제로 필요한 모듈(qtbase, qtcharts, qtserialport, ..)만 사용할 수 있습니다.

• 직접 종속성을 말하면 Conan(패키지 관리자)이 나머지, 즉 종속성과 정확한 버전을 처리합니다.

• 프로젝트가 또 다른 라이브러리에도 의존해야 합니까?

• Conan 센터: OpenSSL , Protobuf , CMake , Boost , sqlite3 , zlib , ..

• 필요한 바이너리/빌드 구성을 찾지 못하셨나요? 제공된 빌드 프로필을 필요에 맞게 편집하고 "--build"를 전달하면 Conan이 소스에서 필요한 모든 것을 빌드합니다. (사용자 환경에 컴파일 도구가 있는 경우) 빌드된 바이너리는 로컬 Conan 캐시에 저장되어 바이너리를 쉽게 재사용할 수 있습니다.

• Conan은 바이너리를 로컬로 캐시하므로 추가 설치가 더 빠릅니다.

여기 에서 Conan 을 설치 하십시오. 최신 버전(1.47)을 사용하는 것이 좋습니다.

Conan 패키지에 액세스하려면 Qt 계정 의 "Conan 패키지 관리자" 페이지로 이동 하여 Conan 서버에 대한 개인 자격 증명을 생성하십시오.

로컬 구성에 원격 정보를 추가합니다.

conan remote add qt https://qtpkgtest.jfrog.io/artifactory/api/conan/qt

내 서버에 인증:

$ conan user -p PASSWORD -r qt USERNAME

프로젝트에 어떤 종속성이 있습니까?

my_app_deps.txt:
[requires]
qtbase/6.2.4@qt/everywhere
qtdeclarative/6.2.4@qt/everywhere

릴리스 빌드 구성/빌드 프로필에 액세스 할 수 있습니다. 예를 들어 Linux 데스크톱에 설치한 후 필요한 Qt 패키지를 설치합니다.

$ conan install my_app_deps.txt --profile=linux-x86_64-gcc --update --generator=virtualenv --remote=qt
 # wait for the installation to complete ...
$ source activate.sh  # on windows run the activate.bat
# build your app
$ cd <my app dir>
$ cmake CMakeLists.txt
$ cmake --build .
# run your app

여기에 제공된 자세한 내용을 참조 하십시오.

크로스 빌딩을 완전히 지원하기 위해 수정해야 할 부분이 여전히 있습니다. 이전 Qt Conan 6.x Tech Preview 릴리스에서 예를 들어 Android 패키지를 게시했지만 아직 완전히 사용할 수는 없었습니다. 이 작업은 계속됩니다. Boot2Qt 지원도 진행 중입니다.

With Qt Conan 6.2.3 Tech Preview release we included ICU as the first 3rd party package which is a dependency for qtbase (If Qt is configured with 'icu' support). This is also available in Qt 6.2.4 Conan Technology Preview.

CMake, Ninja, OpenSSL, libpng, libjpeg, and many other 3rd party Conan packages are planned to be integrated into Qt Conan packages depending on the build configuration. This means Conan will take care of installing these for you as dependencies, as the package managers do.

We are interested to hear how Qt Conan packages would fit in your workflow? I.e. using Qt "the package manager way". Any of the following feedback channels can be used:

• 작성 : Peter Schneider
• 날자 : 2022년 4월 13일
• 원문 : https://www.qt.io/blog/make-your-app-live-longer
• 번역 : https://j2doll.tistory.com/713

나는 말 그대로 내 기술이 악화되는 것을 볼 수 있었습니다. 내 릴리스는 항상 늦었습니다. 버그가 너무 많았습니다. UI가 오래된 느낌이 들었습니다. 클라우드 기반 B2B 솔루션의 R&D 및 제품 관리를 이끌던 시절이었습니다. 이 솔루션은 백엔드로 Java를 사용하고, 프론트엔드 UI 프레임워크로 Angular JS를 사용했습니다. Java 코드는 15년이 넘었지만 Docker 컨테이너에서 잘 수행되었습니다. 고민하던 UI 프레임워크였다.

Angular JS에는 3년 동안 일부 API만 중단된 몇 가지 마이너 릴리스가 있었습니다. Angular UI 프레임워크의 수석 관리자인 Google이 2016년에 프레임워크를 Angular 2.0으로 업그레이드했을 때 1.x 버전에 대한 바이너리 브레이크가 도입되었습니다. 우리는 Angular JS 1.x에서 Angular 2.x 이상으로 업그레이드하는 것을 주저했습니다. 왜냐하면 그것이 사용자 인터페이스의 완전한 재프로그래밍을 의미할 것이라는 것을 알고 있었기 때문입니다. 한편, 기술 부채는 계속 증가했습니다.

2018년에 기술 부채가 너무 커졌을 때 우리는 Angular 5로 UI의 일부를 코딩하기 시작했습니다. 하지만 또 다른 문제가 있었습니다. Angular는 내가 따라갈 수 있는 것보다 빠르게 주요 버전을 변경했습니다. 때로는 12개월 이내에 다양한 API 비호환성과 함께 세 가지 주요 릴리스를 도입했습니다. 우리는 기존 기술 부채를 따라 잡으려고 노력했지만 이미 새로운 부채를 모았습니다. 이것은 비용이 많이 드는 운동이었습니다. 악순환이었습니다. 나는 작년에 Qt Company에서 일하기 위해 그 쇼를 떠났지만, 나는 나의 이전 동료들이 여전히 그것으로 어려움을 겪고 있다는 것이 두렵습니다. 흥미로운 점을 유지하기 위해 Angular는 현재 마이크로 프론트엔드 아키텍처 도입을 고려하고 있습니다. 기존 제품에 어떤 의미가 있는지 궁금합니다.

수년간 Google의 Angular JS 및 Angular를 사용하면서 배운 것이 있다면 수명이 긴 솔루션에 어떤 기술 프레임워크를 사용할지 다시 한 번 생각해야 한다는 것입니다. 5년 이상 지속되어야 하는 앱을 개발하는 경우 최신 과대 광고 기술이 10년 동안 최고의 총 소유 비용을 제공하지 못할 수 있습니다.

기술 부채는 인간의 노화와 같습니다. 당신은 그것을 피할 수 없습니다. 첫 번째 버전을 출시하면 소프트웨어 복잡성이 증가하고 버그를 수집하기 시작합니다. 수명이 긴 애플리케이션에 대한 기술 부채를 관리하는 단일 방법은 없습니다. 그러나 알려진 예방 조치에는 다음이 포함됩니다.

• 새로운 기능과 품질의 균형을 맞추기 위한 백로그 관리
• 기술 부채를 청산할 수 있는 문화 만들기
• 마이크로 서비스 아키텍처로 리팩토링 간소화
• 코드 검토 및 코드 문서 승인
• 5년 이상 동안 기술 발전을 사전에 계획

장기적인 기술 로드맵을 계획하는 것은 단순히 큰 거래나 다음 릴리스를 얻는 데 집중할 때 우선 순위가 낮을 수 있습니다. 그러나 어쨌든 우선 순위를 정하는 데에는 그만한 이유가 있습니다. 당신은 아마도 당신의 R&D 팀이 스스로 만들고 있는 기술 부채로 충분히 바쁠 것입니다. 따라서 오픈 소스 기술에서 바이너리 중단 또는 더 이상 사용되지 않는 API와 같은 외부 요인으로 인한 기술 부채를 최소화하고 싶을 것입니다.

모든 오픈 소스 UI 프레임워크와 모든 소프트웨어 개발 키트에도 약간의 기술 부채가 있습니다. 일부는 더 많은 중단을 일으키고 일부는 극적으로 덜합니다. 이전에 Angular(JS)에서 겪었던 문제에 대해 설명했습니다. 모바일 앱 개발을 위한 일부 다른 UI 프레임워크는 2년 동안 API 안정성을 보장하지 않고 Angular처럼 작동합니다. 스펙트럼의 다른 쪽 끝에는 Qt와 같은 소프트웨어 개발 플랫폼이 있습니다. Qt는 18개월마다 LTS(장기 지원) 릴리스를 제공하여 코드 이전 버전과의 호환성과 API 안정성을 5년, 때로는 더 길게 제공합니다.

이 안정성은 지속적인 개발자 리소스로 다음을 수행하는 데 도움이 됩니다.

• 기술 부채에 소요되는 개발자 시간을 줄여 출시 시간을 단축합니다.
• 외부 영향이 적기 때문에 릴리스 로드맵을 더 잘 예측합니다.
• 자체 버그를 수정하는 것이 충분히 끔찍하기 때문에 개발자 만족도를 향상합니다.
• Qt의 예측 가능한 릴리스 일정과 동기화하여 기술 로드맵을 계획합니다.

당연히 Qt 프레임워크도 기술 부채를 수집하고 결국 코드를 ​​정리해야 합니다. 그러나 Qt 는 다른 프레임워크보다 기술 부채를 처리하는 데 더 부드러운 접근 방식을 가지고 있습니다. 2020년에 Qt는 이전 릴리스와 100% 이전 버전과 호환되지 않는 주요 릴리스를 도입했습니다. 이전 릴리스에는 8년 간의 제품 향상으로 인해 상당한 양의 기술 부채가 있었습니다. Qt는 고객이 투자를 보호할 수 있도록 업그레이드 마이그레이션 도구를 제공했습니다. 또한 Qt도 제공했습니다. 구독 고객이 기존 투자를 보호하기 위해 추가 비용 없이 이전 릴리스에 대한 추가 2년 지원. 이는 Qt 5 시리즈에서 최대 12년 이상의 이전 버전과의 호환성과 다음 주요 릴리스로의 명확한 마이그레이션 경로를 추가합니다.

모든 것은 결국 늙는다. 소프트웨어 응용 프로그램의 기술 부채를 처리하는 방법은 우리의 선택입니다. Qt 프레임워크에 대해 더 알고 싶다면 이 페이지 를 확인하세요 .