리눅스용 앱 개발

 (makealinux.app)
1P by GN⁺ | ★ favorite | 댓글 1개
  • Linux 데스크톱·모바일에는 새 소프트웨어 수요가 있지만 앱 스토어와 저장소의 애플리케이션 수가 부족해, 새 배포판보다 앱 개발에 집중하자는 메시지임
  • 개인의 필요에서 출발한 앱도 공개 개발을 거치면 학습 자료와 커뮤니티가 되어 Linux 생태계 확장으로 이어질 수 있음
  • 수백 개 배포판이라는 다양성은 부담이지만, 문서화된 패키징·배포 시스템을 활용하면 여러 환경의 사용자에게 앱을 전달할 수 있음
  • GNOME, KDE Frameworks, elementary OS, Electron, Ubuntu Touch는 Gtk, Qt, Vala, JavaScript·HTML·CSS, QML 등 서로 다른 개발 경로를 제공함
  • AppCenter, AppImage, Flatpak, Open Build Service, Snapcraft 같은 배포 수단이 있으며, 유료 앱·서비스와 후원형 앱 스토어를 통한 수익화 가능성도 있음

Linux에 더 많은 앱이 필요한 이유

  • 데스크톱과 모바일 Linux 사용자는 새 소프트웨어에 대한 수요가 있음
  • Linux 앱 스토어와 저장소는 독점 플랫폼에 비해 애플리케이션이 부족함
  • 기술 애호가에게는 새 Linux 배포판을 더 만들기보다 Linux 사용자를 위한 새 애플리케이션에 열정과 창의성을 쓰라는 권유가 이어짐
  • 핵심 메시지는 “Linux 배포판을 그만 만들고 애플리케이션을 만들라”는 것임

앱 개발이 생태계에 주는 효과

  • 개인적으로 필요한 앱 아이디어가 있다면 비슷한 필요를 가진 다른 사용자도 있을 수 있음
  • 공개적으로 애플리케이션을 만들면 더 새로운 개발자도 배우고 시작할 수 있어 다음 세대 Linux 앱 개발에 도움이 됨
  • 애플리케이션 개발은 창의적인 작업이며, 프로젝트를 완성했을 때의 성취감도 보상이 될 수 있음
  • 앱 개발은 커뮤니티 형성을 돕고, Linux 커뮤니티는 개발자가 성공하도록 돕고 싶어 하는 경우가 많음
  • 소프트웨어 개발 역량은 수요가 있는 기술이며, 무료 학습 리소스도 많음
  • Linux 사용자가 개발자를 재정적으로 지원하지 않는다는 생각은 오해이며, 인기 있는 유료 앱과 서비스로 새로운 수입원을 만들 수 있음

다양한 Linux 배포판을 대상으로 하기

  • Linux는 다른 플랫폼과 달리 매우 다양한 대상이며, 수백 개의 배포판이 존재함
  • 애플리케이션은 한 번 게시되면 일반적으로 여러 환경에서 동작할 수 있음
  • 잘 문서화된 패키징·배포 시스템이 있어 개발자가 사용자에게 앱을 전달할 수 있음
  • 각 개발 프레임워크와 Linux 배포판은 사용자에게 앱을 전달하는 권장 경로를 가짐
  • 앱을 공유할 준비가 되면 개발 문서에서 추천 패키징 가이드를 확인할 수 있음

개발을 시작할 수 있는 경로

  • GNOME

    • GNOME 프로젝트는 GNOME Shell 데스크톱을 만들며, Gjs와 Gtk 기반 개발을 지원함
    • Gtk에서는 Python, C, C++, Rust, JavaScript 등 인기 있는 언어를 사용할 수 있음
    • GNOME Developer Center

  • KDE Frameworks

    • KDE는 Plasma 데스크톱과 애플리케이션 제작 도구·프레임워크를 제공함
    • KDE Frameworks는 다양한 데스크톱 애플리케이션 개발에 사용되어 왔음
    • 주로 Qt 툴킷과 C++ 프로그래밍 언어를 활용함
    • KDE Frameworks Getting Started

  • elementary OS

    • elementary OS는 Windows와 macOS를 대체하는 빠르고 개방적이며 개인정보를 존중하는 운영체제를 지향함
    • 개발자들은 앱 개발을 위한 데스크톱과 생태계를 구축함
    • 개발자 가이드는 Vala와 Gtk를 권장함
    • elementary OS Developer Guide

  • Electron

    • Electron은 JavaScript, HTML, CSS로 크로스플랫폼 데스크톱 앱을 만들 수 있게 함
    • 개발자는 방대한 node 모듈 라이브러리를 활용해 웹 기술 기반 앱을 만들 수 있음
    • Electron Documentation

  • Ubuntu Touch

    • Ubuntu Touch는 휴대폰, 태블릿, PC 등 다양한 기기에서 동작하도록 설계된 오픈소스 운영체제임
    • 네이티브 Ubuntu Touch 앱은 QML 또는 HTML로 만들고, 동작은 JavaScript, C++, Python, Rust, Go로 정의함
    • Ubuntu Touch Documentation

Linux 앱 생태계에 대한 개발자 의견

  • GNOME Foundation의 Neil McGovern은 Linux를 대중에게 가져가려면 번성하는 앱 생태계가 필요하며, 모두가 Linux용 개발을 할 수 있어야 열린 데스크톱이라는 목표에 가까워진다고 봄
  • KDE e.V.의 Aleix Pol은 원하는 운영체제로 Linux를 만들려면 훌륭한 앱이 필요하며, 개발 도구를 통해 상상한 것을 만들 수 있다고 말함
  • elementary 창립자 Daniel Foré는 데스크톱 Linux에서 훌륭한 앱을 만들 뿐 아니라 플랫폼 API를 만들고 데스크톱의 방향에 영향을 줄 기회가 있다고 봄
  • UBports Foundation 이사회 구성원 Jan Sprinz는 Linux 앱 개발이 닫힌 생태계와 완전히 다르며, 기술적으로 경쟁하더라도 더 큰 비전을 위해 협력한다고 말함

앱을 공유하고 배포하는 방법

  • AppCenter

    • 독립 개발자를 위한 공개형 pay-what-you-want 앱 스토어이자 빌드 서비스임
    • AppCenter Dashboard는 GitHub와 통합되어 릴리스와 이슈 추적을 지원함
    • AppCenter Dashboard

  • AppImage

    • 데스크톱 Linux 애플리케이션을 AppImage 형식으로 배포해 일반적인 Linux 배포판 사용자에게 도달할 수 있음
    • 한 번 패키징해 어디서나 실행하는 방식을 내세움
    • AppImage Packaging Guide

  • Flatpak

    • Linux 데스크톱 애플리케이션 배포를 위한 프레임워크임
    • Linux 데스크톱에서 오래 일해 온 개발자들이 만들었고, 독립 오픈소스 프로젝트로 운영됨
    • Flatpak Documentation

  • Open Build Service

    • openSUSE Build Service는 Open Build Service의 공개 인스턴스임
    • openSUSE 배포판 개발과 함께 Fedora, Debian, Ubuntu, SUSE Linux Enterprise 등 여러 배포판용 패키지를 같은 소스에서 제공하는 데 사용됨
    • openSUSE Build Service Help

  • Snapcraft

    • Snapcraft는 snaps를 만들기 위한 명령줄 도구임
    • snaps는 데스크톱, 클라우드, IoT용 앱 패키지이며 설치가 쉽고, 안전하고, 크로스플랫폼이며, 의존성이 없다고 소개됨
    • Snapcraft Documentation

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • Linux에 ABI 안정적인 핵심 프레임워크 묶음이 아직 없다는 점에서 전제가 틀렸다고 봄
    경쟁 플랫폼에는 CoreImage, CoreAudio, CodeML, SceneKit, AppKit 같은 기본 프레임워크가 훨씬 많고, 덜 자주 깨짐
    Linux의 snap이나 flatpak도 흥미롭긴 하지만, 앱을 쓰라고 요구하는 프레임워크와 프로그래밍 언어 자체에서 해결하는 대신 인프라와 패키지 관리로 우회하는 방식에 가까움

    • Linux 애호가 커뮤니티는 이런 방향을 적극적으로 반대하는 편임. 모든 것을 모듈식으로 만들고 특정 애플리케이션에 맞게 조립하기를 원하기 때문임
      Linux에도 사실상의 표준 묶음은 있지만, 바뀌고 폐기되는 게 있어서 안정성이 덜함. 그래도 겉보기보다는 낫고, Snaps로는 일부 문제를 완화할 수 있음
      다만 사람들이 그런 표준이 없는 배포판을 선택하면, 온갖 특이한 설정을 지원하지 않는 순간 잠재 사용자 절반을 잃게 됨
    • 지금 Linux에서 가장 안정적인 대상은 Wine이나 Proton을 통한 Win32라고 어디선가 읽은 적 있음
    • 그 핵심은 GNOME이나 KDE 프레임워크와 FreeDesktop 표준이었고, 적어도 20년 전 계획은 그랬음
      하지만 글에서 말하듯 대부분은 계속 배포판을 만드는 데 집중하고, 자연히 수많은 특이 배포판을 모두 따라갈 단일 스택은 생기기 어려움
      결국 Google은 Linux 커널을 가져다가 Java와 JavaScript 기반의 핵심 프레임워크 두 묶음을 얹었고, 일반 소비자에게는 그 Linux 배포판들이 승자가 됨
    • 주된 책임은 glibc 개발자들에게 있다고 봄. 버전 이름 남용과 최근 새 ELF 재배치 타입 추가 같은 일이, 여러 배포판을 아우르는 게임 바이너리 배포를 고통스럽게 만듦
      보통 게임 개발자는 최신 대형 배포판에서 빌드해 Steam에 올리는데, 그 배포판에 glibc 2.36이 있으면 바이너리도 glibc 2.36 이상을 요구하는 버전 이름을 갖게 되는 경우가 많음
      결국 binutils gas의 symver 지시자를 써서 적당히 오래된 glibc와 호환되는 버전 이름을 강제로 맞춰야 함. 개인적으로는 5년, 어쩌면 7~8년 정도를 합리적인 기준으로 봄: https://sourceware.org/glibc/wiki/Glibc%20Timeline
      일반 게임 개발자는 이런 문제를 거의 모르고, 알아도 시장 1%를 위해 그렇게 고통스러운 작업을 하지는 않을 것임. libgcc와 C++라면 libstdc++도 정적으로 링크해야 그 ABI 문제를 피할 수 있음
      그래도 Godot 엔진이 이런 점을 신경 쓴 빌드 컨테이너를 제공하고 있고, Unity도 그쪽은 깔끔해 보임. UT5.x는 잘 모르겠음
      반면 Electron 기반 게임처럼 준비가 안 된 엔진도 있음. Enlightenment, Qt, 순수 X11, Wayland 같은 배포판에 맞는 GTK+ 버전이 없으면 실행되지 않을 수 있음
      넓은 범위의 ELF/Linux 배포판을 대상으로 Google Blink 엔진 전체를 제대로 패키징해 바이너리 배포한다는 것도 쉽지 않음
      ELF/Linux는 전반적인 ABI 파손 때문에 바이너리 전용 배포에 적대적이고, 특히 SDK와 핵심 라이브러리에서 심함
      게임 바이너리도 이 정도로 어렵다면 앱은 더 힘들 것임. 개발자들이 결국 “상관없고 Microsoft SUSE GNU/Linux만 설치해서 써라, 나머지는 지원 안 한다”고 할 그림이 보임
    • macOS가 제공하는 수준의 프레임워크 폭이 Linux에 있다면, 개인 프로젝트도 진작 Linux를 대상으로 만들었을 것임
      지원 기간, 어느 포크가 나은지, 다른 서드파티 라이브러리와 잘 맞는지 같은 걸 거의 신경 쓰지 않고 바로 꺼내 쓸 도구가 많다는 건 대단함. 마찰을 크게 줄여서 그냥 만들게 해줌
      KDE Qt 생태계와 GNOME/GTK 쪽이 가장 가깝지만 아직 그 수준은 아님

  • 패키지 이름에서 dev와 version을 언제 붙여야 하는지, 뒤에 붙는 임의의 1이나 0이 뭘 의미하는지 결정하는 패턴을 모르는 걸 수도 있지만, 일관된 패키지 이름 규칙을 가진 첫 Linux 배포판이 마음을 얻을 것 같음
    libgnutls-dev
    libgtk-3-0
    libwayland-server0
    libxcb1
    libx11-6
    libffi-dev
    libncurses5-dev

    • -dev는 헤더를 담고 있어서 꽤 쉬운 편임
      숫자는 동시에 여러 버전을 설치할 수 있을 때의 버전 표시임. 다만 xcb1처럼 라이브러리 이름 일부인 경우는 예외일 수 있음
      예를 들어 어느 시점에는 libgtk-3-0과 libgtk-2-$something을 동시에 설치할 수 있었을 것임. 나중에 libgtk-2를 제거해도 기존 튜토리얼의 libgtk-3-0 참조가 깨지지 않도록 이름을 남겼을 가능성이 큼
      libwayland-server0의 끝 0은 나도 잘 모르겠음. /var/lib에 같은 라이브러리가 여러 .$number 꼬리를 달고 있는 건 보지만, 그게 정확히 뭘 해결하는지는 파본 적 없음
    • 바이너리와 소스를 나누는 건 Debian 관례임. 라이브러리를 쓰기만 한다면 -dev가 아닌 패키지로 충분하고, 그 라이브러리로 개발하려면 헤더를 설치하는 -dev도 필요함
      뒤의 1이나 0은 특별한 게 아니라 패키지 이름이나 버전의 일부일 뿐임
    • Arch와 그 파생 배포판에는 이런 게 대체로 없음
      다만 -dev는 그 라이브러리를 대상으로 개발할 때만 필요한 것들을 뜻함
      숫자는 주 버전 번호, 즉 호환성 번호임. 덕분에 서로 다른 패키지가 의존하는 여러 주 버전을 충돌 없이 쉽게 같이 설치할 수 있음
    • 프로그램을 빌드한다면 -dev 패키지를 설치하면 됨. 번호가 붙은 -dev 패키지는 보통 직접 신경 쓸 일이 없고, 필요하면 번호 없는 패키지가 전달해 주는 식이어야 함
      빌드 중에는 어떤 번호 접미사, 즉 ABI 버전이 쓰였는지가 기록됨. 이는 .so.N 접미사와 같아야 하지만 직접 그런 식으로 찾는 건 아님
      이 방식 덕분에 호환되지 않는 라이브러리 복사본 여러 개를 설치하고, 적절한 쪽이 사용될 수 있음. 배포판은 보통 큰 릴리스마다 오래된 것들을 정리함
      설치할 때는 빌드 중 기록된 의존성을 자동으로 쓰게 되어야 함
    • GoboLinux가 있고, 내 관점에서는 모든 걸 해결하면서도 Nix만큼 복잡하지 않음. 하지만 아무도 신경 쓰지 않았음

  • 이건 Linux 플랫폼 전체를 붙잡는 가장 큰 문제 중 하나임. 흔히 장점으로 말하지만 그렇게 보지 않음
    개발자들은 선택지가 많다는 걸 Linux의 장점으로 내세우지만, 많은 사용자에게는 선택의 역설이 되고 원래 쓰던 플랫폼으로 돌아가게 만듦
    macOS와 Windows에서는 선택지가 적지만, 가능한 선택지는 훨씬 더 다듬어져 있고 덜 파편화되어 있음
    예를 들어 타일링 창 관리자가 몇 개나 필요할까? 최고의 타일링 창 관리자를 골라 더 나은 독과 애플릿을 만들 수는 없을까? 타일링 창 관리자 패러다임에 통합되는 앱과 런처는 어떨까?
    대신 타일링 창 관리자 10종과 그 위에 얹힌 반쪽짜리 우회 프로그램들만 남는 경우가 많음

    • 사람들은 모든 선택지를 exhaustive하게 분석해서 고르지 않음. 소수의 후보를 보고 인기나 접근성에 따라 하나를 골라 쓰는 식임
      성공적인 생태계는 눈에 잘 띄는 선택지를 골라도 충분히 괜찮은 결과가 나오게 해줌
      Linux 배포판이 늘어나는 건 대부분 의미 있는 적합성을 떨어뜨리지 않는 작은 차이일 뿐이고, 배포판을 고르는 데 별 어려움이 없던 극소수만 문제로 여김
      반대로 Wayland 같은 경우는 배관과 하드웨어가 갑자기 중요해지고, 쓸 만한 조합을 고르려면 내부 구조를 어느 정도 알아야 하므로 실제 문제가 됨
      Mac이나 Windows를 Linux와 비교하는 것도 별 의미가 없음. 소비자 95%에게 운영체제는 컴퓨터의 고정된 특성이거나 기능이지, 별도 제품이 아님
      전체 패키지가 맞으면 그 운영체제가 깔린 컴퓨터를 살 수는 있어도, 자기 Windows나 Mac 기기에 따로 설치하려 하지는 않음
      만족할 만큼 기술 지식이 있는 사람들은 Ubuntu 파생판 3개와 Arch 파생판 2개가 더 생겨도 크게 혼란스러워하지 않을 것임
    • 타일링 창 관리자를 만드는 건 재미있음. 협업으로 소프트웨어를 만드는 건 어떤 결과물을 얻기 위한 수단일 뿐 아니라 그 자체가 목적임
      오픈소스 개발자가 된다는 건 목표와 수단을 스스로 정할 수 있다는 뜻이고, 상업 소프트웨어 개발에서는 그런 자유가 없는 경우가 많음
      거친 부분은 생기지만, IKEA 효과가 작동해서 결국 좋아하게 됨
    • 이 문제는 배포판이 해결해야 하는 영역임. 선택지가 많기를 원하지 않는 사람은 많은 선택을 대신 내려주는 배포판을 쓰면 되지, 생태계 전체에서 선택지를 없애라고 밀어붙일 필요는 없음
      모두가 같은 소프트웨어를 쓰면 공격에 더 취약한 단일 재배 생태계가 됨. Windows가 바이러스의 표적이 많이 된 이유도 대상이 크고 일관됐기 때문임
      한 일반 사용자의 Windows 머신을 뚫으면 나머지도 비슷하게 뚫을 수 있었음. Linux를 대상으로 하면 훨씬 어려움
      게다가 자유 소프트웨어임. 누군가에게 돈을 주고 시키는 게 아니라면 대부분은 자원봉사 활동이고, 남의 자원봉사 시간을 어디에 쓰라고 우리가 말할 수는 없음
      이렇게 많은 그룹이 있는데도 아무도 합류하고 싶어 하지 않는다면 지배적인 사회 구조도 돌아봐야 함. 프로젝트 밖 행동까지 처벌할 수 있게 하는 행동 강령부터 없애보는 게 출발점일 수 있음
    • 타일링 창 관리자보다 런처와 독이 더 많다고 봄
      그리고 뭘 더 개선해야 하는지도 잘 모르겠음. Ulauncher나 Albert 같은 건 다른 플랫폼에서 가능한 것보다 훨씬 강력하고, UI를 어떻게 더 낫게 만들 수 있을지도 모르겠음
    • 사람들이 만들고 싶은 만큼의 타일링 창 관리자가 있으면 됨

  • 소프트웨어가 더 많아지는 건 좋음. 다만 처음부터 새로 만들기 전에 이미 있는 것에 기여하거나, 버려졌거나 최신 컴파일러와 하드웨어에서 빌드·실행되도록 손볼 필요가 있는 프로젝트를 고르면 어떨까 싶음
    되살릴 가치가 있는 휴면·사망 프로젝트 데이터베이스가 어딘가 있는지도 궁금함

    • 이미 있는 무언가가 내가 목표로 하는 방식으로 만들어져 있지 않을 수 있음
      또 다른 프로젝트는 같이 지내기 힘든 사람이 이끌고 있거나, 제안과 패치를 받아들이지 않는 커뮤니티일 수 있음
      사회적 절차와 막힘은 기여 동기를 잃게 만들 수 있음. 모두가 성격 없는 낙천적 팀 플레이어가 될 수는 없음
      나로서는 처음부터 새로 시작하는 쪽이 낫다. 모든 변수를 통제할 수 있고, 기존 사회·기술 인프라를 만질 필요가 없고, 내 아이디어가 좋다고 누군가를 설득하지 않아도 되며, 코드보다 논쟁과 토론에 시간을 더 쓰고 싶지 않기 때문임
      솔로 개발 경험이 더 좋음. 정치와 사회적 절차에 묶이지 않기 때문이고, 팀 플레이어가 되어본 건 내게 고통만 줬음
    • 대부분의 분야에는 수준 낮은 시도가 너무 많고, 그 노력을 상위 몇 개 프로젝트에 모으면 훌륭한 앱 몇 개가 나올 수 있음
      협업은 부담스럽고 힘들어 보일 수 있지만, 결국 결과를 내는 일이고 버려질 프로젝트에 쓰는 시간보다 낫게 쓰이는 시간임
    • 주요 Linux 패키지 저장소 중에 많이 쓰이지만 유지보수되지 않거나 기능이 미완성인 앱을 검색할 수 있는 통계를 모으는 곳이 있는지 궁금함

  • 여러 운영체제에서 호환되는 앱을 만들 도구가 부족하다는 불평이 많지만 동의하지 않음. Electron이 아닌 해법만 봐도 있음
    Telegram은 Qt를 써서 세 운영체제 모두에 성능 좋은 네이티브 앱을 배포함
    Flutter는 세 운영체제와 모바일에서 네이티브 코드로 컴파일됨
    Kirigami는 QtQuick 프레임워크로, 모바일과 데스크톱 대상 전부에 실행 가능한 앱을 만들 수 있게 해줌
    그냥 앱을 만들면 됨. 이걸 Linux 비난의 핑계로 삼을 이유는 없음

    • Flutter는 플랫폼마다 살짝 다르게 동작해서 모든 플랫폼에서 미묘하게 좋지 않은 경험을 줌. Kirigami나 Qt Quick도 현실적으로 가능한 선택지라고 보기는 어려움
      Windows, macOS, 모바일에서 커뮤니티나 진지한 프로젝트가 거의 없음. KDE 쪽을 깎아내리려는 건 아니지만 현실이 그렇다
      Qt Quick 라이선스도 iOS에서는 쉽지 않거나, 상업적으로 가면 매우 비쌈
      반면 Electron에는 대기업들이 투자해 매우 다듬어진 프로덕션급 도구를 내놓고 있고, 거대한 커뮤니티와 라이브러리 생태계가 있으며, Dart 같은 생소한 언어도 아님
      Telegram은 정말 한 단계 더 노력함. 클라이언트가 훌륭함
    • Qt 기반 Telegram 앱도 macOS에서 잘 돌아가지만, 대부분의 Apple 사용자는 macOS와 iOS용 Swift/Cocoa 클라이언트를 고름[0]
      [0]: https://github.com/overtake/TelegramSwift

  • 문제는 OSS 소프트웨어가 시장과 경쟁하려는 시도조차 잘 하지 않는 데 있음
    OSS 소프트웨어를 쓰는 사람들은 UX가 부족할 거라고 당연하게 받아들이고, 실제로도 그런 경우가 많음
    일반 독점 소프트웨어는 사용자가 돈을 안 낼 위험이 있어서 최종 사용자 경험을 좋게 만들도록 적응하지만, OSS에는 보통 그런 위험이 없음. 오픈소스도 최종 사용자로부터 오는 위험에 노출될 필요가 있음
    Notes[1]로 그걸 바꾸려 했지만 광고만으로 먹고살기는 어렵다는 걸 느낌. Kanban 같은 프리미엄 기능 결제도 넣어봤지만 앱이 완전한 FOSS라 누구나 소스에서 쉽게 컴파일할 수 있음
    다음 앱[2]은 출시 전에 비공개 소스로 돌릴 생각임. 내 노력이 보상받지 못할 위험을 감수할 수 없음
    돈을 받을 수 있으면 Linux에서 UX 중심 앱에 더 투자할 수 있으니 Linux 커뮤니티에도 도움이 된다고 믿음. 일부는 오픈소스로 공개할 수도 있고, 먼 미래에는 전체를 공개할 수도 있음
    [1] https://github.com/nuttyartist/notes
    [2] https://www.get-plume.com

    • Linux 사용자와 자유를 소중히 여기는 사람들의 교집합은 큼. 많은 사람에게 비오픈소스 노트 앱은 벤더 종속과 개인정보 문제 때문에 처음부터 선택지가 아님
      그래서 프로그램을 오픈소스로 만들지 않으면, 오픈소스로 만들고 일부가 돈을 안 낼 위험을 감수하는 것보다 더 많이 잃을 가능성이 큼
      독점 소프트웨어를 쓰려는 사람보다 돈을 내고서라도 오픈소스를 쓰려는 사람이 훨씬 많을 것이라고 봄
      오픈소스라고 해서 모두에게 코드를 배포해야 하는 건 아니고, 돈을 받는다면 유료 사용자에게만 소스 코드를 줄 수도 있음. 다만 그들은 수정과 재배포 권리를 갖게 됨
      오픈소스에 관심이 없다면 Notion이나 Evernote를 쓰면 됨. 최신형 오픈소스 노트 앱을 찾는다면 Logseq를 추천함
    • 올바른 결정을 하는 것 같음. 오픈소스로 생계 수준의 돈을 버는 건 극도로 어렵고, 상업 소프트웨어로 먹고사는 사람보다 규모가 몇 자릿수나 적음
    • 답답함은 이해하지만 반례도 있음. 깎아내리려는 의도는 아님
      첫째, Notes는 Standard Notes와 꽤 비슷해 보임. 카피레프트 OSS를 사용해 Notes를 만들었다면, 그 안에 포함된 다른 프로그래머들의 작업에 로열티를 내지 않는 한 불평하기 어렵다고 봄
      둘째, 나는 아마 비전형적인 사용자임. Linux를 20년 넘게 썼지만 Bash 스크립트나 Perl 한 줄도 제대로 못 씀
      그런데 코딩을 못 하고 다른 사람의 작업과 그것이 주는 자유를 고맙게 여기기 때문에, 다른 플랫폼에서 개인들이 보통 쓰는 것보다 훨씬 많은 돈을 소프트웨어에 써왔음
      Kaisen과 Debian, FSF의 핵심 유틸리티와 Emacs, KDE, Mozilla의 Firefox, Betterbird, Syncthing, LaGrange, Joplin, ClipTo, SoulSeek와 envs.net 같은 서비스 등 여러 곳을 지원함
      어떤 것은 매년, 어떤 것은 매월, 어떤 것은 한 번만 냄
      Standard Notes가 처음 나왔을 때도 7년 구독을 결제했지만, 두 달쯤 쓰고 만족하지 못해 그만둠. Alacritty처럼 많이 쓰지만 기부 방법을 찾지 못한 것도 있고, 그런 경우는 최소화하려고 함
    • 개인적으로 KDE는 macOS와 Windows보다 훨씬 앞서 있다고 봄
      사실 macOS는 인기 플랫폼 중 최악의 창 관리자 중 하나라고 느낌. 예쁘고 쓰기 쉽긴 하지만, 기본을 넘어서 뭔가 하려면 자연스럽게 발견할 수 없는 마법 주문이 필요함
      물론 각자 취향은 다름
    • 몇 가지 생각이 있음. 이 분야를 꽤 따라가는데도 그 앱은 들어본 적이 없고, 경쟁이 극도로 치열함
      프리미엄 가격을 보러 눌러봤는데 연간 기준으로는 합리적이지만 월 구독 옵션만 보여서 그건 어렵다고 느꼈음
      이런 앱에서는 프리미엄 버전 결제보다 기부를 할 가능성이 더 큼. Obsidian은 그 모델이 잘 작동했음
      기능 조기 접근은 큰 가치가 없다고 보지만, 작업을 지원하기 위해 돈을 낸 사람은 많음
      또 닫힌 핵심 제품 주변에 큰 오픈소스 생태계가 있는 구조는 사람들이 돈을 낼 이유를 만들어준다고 봄

  • 글에 예시가 몇 개 있으면 좋았을 것 같음
    배포판을 만들고 있는데 사실은 애플리케이션을 만들어야 할 사람은 잘 떠오르지 않음. 억지로 보면 LinuxCNC 정도일까? 하지만 그건 특정 커널 요구사항이 있어서 커스텀 배포판이 더 맞을 수도 있음

    • 데스크톱 환경은 사실상 한두 번의 클릭이나 명령으로 쉽게 설치할 수 있는 애플리케이션임
      파생의 파생 배포판이 단지 다른 데스크톱 환경을 담아 배포되는 건 이해가 잘 안 됨

  • “Linux 배포판 그만 만들고, 애플리케이션을 만들어라”라기보다, 뭘 해야 하고 말아야 한다고 지시하려는 사람들 말을 그만 듣는 게 낫다고 봄

    • 나도 그 어조가 거슬렸음
      그래도 메시지와 정보 자체는 좋음
      개인적으로는 “Linux 사용자는 배포판을 더 원하지 않는다. 소프트웨어를 원한다” 정도로 말했을 것 같음. 적어도 나는 그럼
    • 뭘 해야 하고 말아야 한다고 지시하려는 사람들 말을 그만 들으라는 사람들의 말도 그만 들어야 함. 모든 게 상대적인 건 아니고, 좋은 선택과 나쁜 선택은 있음

  • 최근 Mac에서 Linux로 옮겼고, 성능 좋은 중고 장비를 일상용 머신으로 쓰기 위해서였음
    이전에도 여러 머신에 Linux를 설치해봤지만 이번에는 단순한 취미가 아님
    Ubuntu는 내 하드웨어와 주변기기를 잘 지원하지만, 앱 스토어는 미완성이고 억지로 끼워 넣은 느낌임. 그래도 거의 모든 것이 기대대로 작동함
    Mint, Debian, Arch도 확인해보고 싶지만 Ubuntu를 염두에 두고 작성된 소프트웨어가 많아 보여 조심스러움

    • Linux Mint는 Ubuntu 기반이라 Ubuntu 패키지를 문제없이 쓸 수 있음. 사실상 더 나은 Ubuntu라고 봐도 됨
      Debian 기반 Mint 버전도 있지만, 그건 Ubuntu 쪽에 치명적으로 의존하지 않기 위한 안전장치에 가까움
      요즘은 특이한 배포판을 써도 크게 문제가 되지 않음. 기본 패키지 관리자가 원하는 앱을 제공하지 않으면 AppImage, Flatpak, Snap을 쓸 수 있기 때문임
    • Ubuntu용으로 작성된 것 중 Arch나 대부분의 최신 배포판에서 안 돌아갈 만한 건 거의 없음
      Arch를 쓸 때는 사람들이 Ubuntu를 기준으로 하는 가정에 익숙해질 필요가 있었지만, 대부분 설정 파일을 패치하거나 환경 변수를 잡는 정도였음
      그런 건 유용하고 다른 곳에도 옮겨 쓸 수 있는 기술임
    • Fedora도 꼭 한 번 써보는 게 좋음
      더 일찍 써봤으면 좋았겠다고 생각함

  • 왜 누가 그렇게 하겠나 싶음. 더 어렵고, Linux 사용자는 돈 낼 가치가 없는 것에는 돈을 내지 않음

    • 세상에는 좋은 무료 소프트웨어가 더 많아지면 이롭기 때문임
답변달기