Phát triển ứng dụng cho Linux

 (makealinux.app)
1 điểm bởi GN⁺ 2023-12-11 | 1 bình luận | Chia sẻ qua WhatsApp
  • Desktop và di động Linux có nhu cầu với phần mềm mới, nhưng các app store và kho phần mềm đang thiếu số lượng ứng dụng, nên thông điệp là hãy tập trung vào phát triển ứng dụng hơn là tạo thêm bản phân phối mới
  • Ngay cả những ứng dụng bắt đầu từ nhu cầu cá nhân, nếu được phát triển công khai, cũng có thể trở thành tài liệu học tập và cộng đồng, từ đó dẫn đến mở rộng hệ sinh thái Linux
  • Sự đa dạng với hàng trăm bản phân phối là một gánh nặng, nhưng nếu tận dụng các hệ thống đóng gói và phân phối đã được tài liệu hóa, vẫn có thể đưa ứng dụng đến người dùng ở nhiều môi trường khác nhau
  • GNOME, KDE Frameworks, elementary OS, Electron, Ubuntu Touch cung cấp các lộ trình phát triển khác nhau với Gtk, Qt, Vala, JavaScript·HTML·CSS, QML...
  • Có các phương thức phân phối như AppCenter, AppImage, Flatpak, Open Build Service, Snapcraft; đồng thời cũng có khả năng kiếm tiền thông qua ứng dụng trả phí, dịch vụ và các app store theo mô hình ủng hộ

Vì sao Linux cần nhiều ứng dụng hơn

  • Người dùng Linux trên desktop và di động có nhu cầu đối với phần mềm mới
  • Các app store và kho phần mềm Linux thiếu ứng dụng so với các nền tảng độc quyền
  • Với những người đam mê công nghệ, ngày càng có nhiều lời kêu gọi hãy dành đam mê và sự sáng tạo cho ứng dụng mới phục vụ người dùng Linux thay vì tạo thêm các bản phân phối Linux mới
  • Thông điệp cốt lõi là: “Hãy ngừng tạo bản phân phối Linux và bắt đầu làm ứng dụng”

Tác động của phát triển ứng dụng đối với hệ sinh thái

  • Nếu có ý tưởng về một ứng dụng mà bản thân cần, rất có thể cũng có những người dùng khác có nhu cầu tương tự
  • Nếu xây dựng ứng dụng một cách công khai, các nhà phát triển mới hơn cũng có thể học hỏi và bắt đầu, qua đó hỗ trợ thế hệ phát triển ứng dụng Linux tiếp theo
  • Phát triển ứng dụng là công việc sáng tạo, và cảm giác thành tựu khi hoàn thành dự án cũng có thể là một phần thưởng
  • Phát triển ứng dụng giúp hình thành cộng đồng, và cộng đồng Linux thường muốn giúp nhà phát triển thành công
  • Năng lực phát triển phần mềm là kỹ năng có nhu cầu cao, và cũng có rất nhiều tài nguyên học tập miễn phí
  • Quan niệm rằng người dùng Linux không hỗ trợ tài chính cho nhà phát triển là một hiểu lầm; các ứng dụng và dịch vụ trả phí phổ biến có thể tạo ra nguồn thu mới

Nhắm đến nhiều bản phân phối Linux khác nhau

  • Linux, không giống các nền tảng khác, là một mục tiêu cực kỳ đa dạng, với hàng trăm bản phân phối tồn tại
  • Một khi được phát hành, ứng dụng nói chung có thể chạy trên nhiều môi trường
  • Có các hệ thống đóng gói và phân phối được tài liệu hóa tốt để nhà phát triển đưa ứng dụng đến người dùng
  • Mỗi framework phát triển và mỗi bản phân phối Linux đều có lộ trình khuyến nghị riêng để phân phối ứng dụng đến người dùng
  • Khi sẵn sàng chia sẻ ứng dụng, có thể xem hướng dẫn đóng gói được khuyến nghị trong tài liệu phát triển

Những lộ trình có thể bắt đầu phát triển

  • GNOME

    • Dự án GNOME tạo ra desktop GNOME Shell và hỗ trợ phát triển dựa trên Gjs và Gtk
    • Với Gtk, có thể dùng các ngôn ngữ phổ biến như Python, C, C++, Rust, JavaScript...
    • GNOME Developer Center

  • KDE Frameworks

    • KDE cung cấp desktop Plasma cùng các công cụ và framework để tạo ứng dụng
    • KDE Frameworks từ lâu đã được dùng để phát triển nhiều ứng dụng desktop khác nhau
    • Chủ yếu sử dụng bộ công cụ Qt và ngôn ngữ lập trình C++
    • KDE Frameworks Getting Started

  • elementary OS

    • elementary OS hướng tới một hệ điều hành nhanh, cởi mở và tôn trọng quyền riêng tư, thay thế cho Windows và macOS
    • Các nhà phát triển xây dựng desktop và hệ sinh thái dành cho phát triển ứng dụng
    • Hướng dẫn cho nhà phát triển khuyến nghị Vala và Gtk
    • elementary OS Developer Guide

  • Electron

    • Electron cho phép tạo ứng dụng desktop đa nền tảng bằng JavaScript, HTML, CSS
    • Nhà phát triển có thể tận dụng thư viện module node đồ sộ để tạo ứng dụng dựa trên công nghệ web
    • Electron Documentation

  • Ubuntu Touch

    • Ubuntu Touch là hệ điều hành mã nguồn mở được thiết kế để chạy trên nhiều thiết bị như điện thoại, máy tính bảng và PC
    • Ứng dụng Ubuntu Touch native được tạo bằng QML hoặc HTML, còn hành vi được định nghĩa bằng JavaScript, C++, Python, Rust, Go
    • Ubuntu Touch Documentation

Ý kiến của các nhà phát triển về hệ sinh thái ứng dụng Linux

  • Neil McGovern của GNOME Foundation cho rằng để đưa Linux đến với đại chúng thì cần một hệ sinh thái ứng dụng thịnh vượng, và mọi người đều phải có thể phát triển cho Linux thì mới tiến gần hơn tới mục tiêu về một desktop mở
  • Aleix Pol của KDE e.V. nói rằng để biến Linux thành hệ điều hành mà người dùng mong muốn thì cần những ứng dụng tuyệt vời, và các công cụ phát triển cho phép tạo ra những gì ta hình dung
  • Nhà sáng lập elementary, Daniel Foré, cho rằng trên desktop Linux, không chỉ có cơ hội tạo ra các ứng dụng tuyệt vời mà còn có thể xây dựng API nền tảng và tác động đến định hướng của desktop
  • Jan Sprinz, thành viên hội đồng quản trị UBports Foundation, nói rằng phát triển ứng dụng Linux hoàn toàn khác với các hệ sinh thái đóng; dù có cạnh tranh về kỹ thuật, mọi người vẫn hợp tác vì một tầm nhìn lớn hơn

Cách chia sẻ và phân phối ứng dụng

  • AppCenter

    • Là app store công khai theo mô hình pay-what-you-want dành cho nhà phát triển độc lập, đồng thời cũng là một dịch vụ build
    • AppCenter Dashboard tích hợp với GitHub để hỗ trợ phát hành và theo dõi issue
    • AppCenter Dashboard

  • AppImage

    • Có thể phân phối ứng dụng desktop Linux dưới định dạng AppImage để tiếp cận người dùng của các bản phân phối Linux phổ biến
    • Theo đuổi cách tiếp cận đóng gói một lần, chạy ở mọi nơi
    • AppImage Packaging Guide

  • Flatpak

    • Là framework để phân phối ứng dụng desktop Linux
    • Được tạo ra bởi các nhà phát triển đã làm việc lâu năm trên desktop Linux và được vận hành như một dự án mã nguồn mở độc lập
    • Flatpak Documentation

  • Open Build Service

    • openSUSE Build Service là một instance công khai của Open Build Service
    • Được dùng cùng với việc phát triển bản phân phối openSUSE để cung cấp gói cho nhiều bản phân phối như Fedora, Debian, Ubuntu, SUSE Linux Enterprise... từ cùng một mã nguồn
    • openSUSE Build Service Help

  • Snapcraft

    • Snapcraft là công cụ dòng lệnh để tạo snaps
    • snaps được giới thiệu là các gói ứng dụng cho desktop, cloud và IoT; dễ cài đặt, an toàn, đa nền tảng và không phụ thuộc
    • Snapcraft Documentation

Bài viết liên quan

1 bình luận

 
GN⁺ 2023-12-11
Các ý kiến trên Hacker News

  • Tôi cho rằng tiền đề này sai ở chỗ Linux vẫn chưa có một bộ framework cốt lõi ổn định về ABI
    Các nền tảng cạnh tranh có nhiều framework nền tảng hơn hẳn như CoreImage, CoreAudio, CodeML, SceneKit, AppKit, và chúng ít bị phá vỡ hơn
    snap hay flatpak trên Linux cũng thú vị, nhưng chúng giống một cách đi vòng bằng hạ tầng và quản lý gói hơn, thay vì giải quyết ngay trong chính framework và ngôn ngữ lập trình mà ứng dụng yêu cầu người dùng dùng

    • Cộng đồng người yêu thích Linux thường tích cực phản đối hướng này. Vì họ muốn làm mọi thứ theo kiểu mô-đun và lắp ghép cho phù hợp với từng ứng dụng cụ thể
      Linux thực ra cũng có các bộ tiêu chuẩn trên thực tế, nhưng do có những thứ thay đổi và bị loại bỏ nên độ ổn định kém hơn. Dù vậy, tình hình vẫn tốt hơn vẻ ngoài, và Snaps có thể giảm nhẹ một số vấn đề
      Tuy nhiên, nếu mọi người chọn các bản phân phối không có những tiêu chuẩn đó, thì chỉ cần bạn không hỗ trợ đủ loại cấu hình kỳ lạ là sẽ mất một nửa người dùng tiềm năng
    • Tôi từng đọc ở đâu đó rằng mục tiêu ổn định nhất trên Linux hiện nay là Win32 thông qua Wine hoặc Proton
    • Phần cốt lõi của nó vốn là các framework GNOME hoặc KDE cùng các tiêu chuẩn FreeDesktop, ít nhất kế hoạch 20 năm trước là vậy
      Nhưng như bài viết nói, phần lớn mọi người vẫn tiếp tục tập trung vào việc tạo bản phân phối, nên tự nhiên rất khó xuất hiện một stack duy nhất có thể theo kịp vô số bản phân phối kỳ lạ
      Cuối cùng Google đã lấy kernel Linux rồi đặt lên đó hai bộ framework cốt lõi dựa trên Java và JavaScript, và với người tiêu dùng phổ thông thì các bản phân phối Linux đó đã trở thành bên thắng cuộc
    • Tôi cho rằng trách nhiệm chính thuộc về các nhà phát triển glibc. Những việc như lạm dụng tên phiên bản và gần đây thêm kiểu relocation ELF mới khiến việc phân phối binary game xuyên nhiều bản phân phối trở nên đau đớn
      Thông thường, nhà phát triển game build trên một bản phân phối lớn mới nhất rồi đưa lên Steam; nếu bản phân phối đó có glibc 2.36 thì binary cũng thường sẽ mang tên phiên bản yêu cầu glibc 2.36 trở lên
      Rốt cuộc phải dùng chỉ thị symver của binutils gas để ép tên phiên bản khớp với một glibc đủ cũ ở mức hợp lý. Cá nhân tôi xem 5 năm, có lẽ 7–8 năm, là mốc hợp lý: https://sourceware.org/glibc/wiki/Glibc%20Timeline
      Nhà phát triển game bình thường hầu như không biết vấn đề này, và dù biết cũng sẽ không làm công việc đau đớn như vậy chỉ vì 1% thị trường. Với libgcc và C++, cũng phải liên kết tĩnh libstdc++ để tránh vấn đề ABI đó
      Dù vậy, engine Godot đang cung cấp build container có quan tâm đến những điểm này, và Unity cũng có vẻ xử lý phần đó khá gọn gàng. UT5.x thì tôi không rõ
      Ngược lại cũng có những engine chưa sẵn sàng, như game dựa trên Electron. Nếu không có phiên bản GTK+ phù hợp với bản phân phối như Enlightenment, Qt, X11 thuần hoặc Wayland thì có thể không chạy được
      Việc đóng gói đúng toàn bộ engine Google Blink để phân phối binary nhắm tới một dải rộng các bản phân phối ELF/Linux cũng không dễ
      ELF/Linux nhìn chung không thân thiện với phân phối chỉ có binary vì ABI bị phá vỡ, đặc biệt nghiêm trọng ở SDK và các thư viện cốt lõi
      Nếu binary game đã khó đến mức này thì ứng dụng còn khó hơn. Tôi có thể hình dung các nhà phát triển cuối cùng sẽ nói: “không quan tâm, cứ cài Microsoft SUSE GNU/Linux mà dùng, các thứ còn lại không hỗ trợ”
    • Nếu Linux có độ phủ framework ngang mức macOS cung cấp, các dự án cá nhân của tôi hẳn đã nhắm tới Linux từ lâu
      Việc có nhiều công cụ có thể lấy ra dùng ngay mà gần như không phải bận tâm về thời gian hỗ trợ, fork nào tốt hơn, hay có tương thích tốt với thư viện bên thứ ba khác không là điều rất tuyệt. Nó giảm ma sát rất nhiều và khiến bạn cứ thế làm
      Hệ sinh thái KDE Qt và phía GNOME/GTK là gần nhất, nhưng vẫn chưa đạt tới mức đó

  • Có thể là tôi không biết mẫu quy tắc để quyết định khi nào nên thêm dev và version vào tên gói, hay các số 1 hoặc 0 tùy ý ở cuối có nghĩa là gì, nhưng có lẽ bản phân phối Linux đầu tiên có quy tắc đặt tên gói nhất quán sẽ chiếm được cảm tình
    libgnutls-dev
    libgtk-3-0
    libwayland-server0
    libxcb1
    libx11-6
    libffi-dev
    libncurses5-dev

    • -dev chứa các header nên khá dễ hiểu
      Các con số là chỉ báo phiên bản khi có thể cài đồng thời nhiều phiên bản. Tuy nhiên có thể có ngoại lệ, như xcb1, khi đó nó là một phần của tên thư viện
      Ví dụ, tại một thời điểm nào đó hẳn có thể cài đồng thời libgtk-3-0 và libgtk-2-$something. Rất có khả năng tên này được giữ lại để sau này, dù gỡ libgtk-2, các tham chiếu libgtk-3-0 trong những hướng dẫn cũ vẫn không bị hỏng
      Tôi cũng không rõ số 0 ở cuối libwayland-server0 là gì. Tôi có thấy trong /var/lib cùng một thư viện mang nhiều đuôi .$number, nhưng chưa từng đào sâu xem chính xác nó giải quyết vấn đề gì
    • Việc tách binary và source là thông lệ của Debian. Nếu chỉ dùng thư viện thì gói không có -dev là đủ; nếu muốn phát triển với thư viện đó thì cũng cần gói -dev để cài các header
      1 hay 0 phía sau không có gì đặc biệt, chỉ là một phần của tên gói hoặc phiên bản mà thôi
    • Arch và các bản phân phối phái sinh của nó nhìn chung không có kiểu này
      Tuy vậy -dev nghĩa là những thứ chỉ cần khi phát triển nhắm tới thư viện đó
      Các con số là số phiên bản chính, tức số tương thích. Nhờ vậy có thể dễ dàng cài song song nhiều phiên bản chính mà các gói khác nhau phụ thuộc vào, không bị xung đột
    • Nếu đang build một chương trình thì cứ cài gói -dev là được. Các gói -dev có kèm số thường không phải thứ bạn cần trực tiếp bận tâm; nếu cần thì gói không có số nên chuyển tiếp tới chúng
      Trong quá trình build, hệ thống sẽ ghi lại hậu tố số nào, tức phiên bản ABI, đã được dùng. Nó phải khớp với hậu tố .so.N, nhưng không phải là bạn tự đi tìm theo cách đó
      Cách này cho phép cài nhiều bản sao thư viện không tương thích với nhau, rồi dùng đúng bản phù hợp. Các bản phân phối thường dọn những cái cũ theo từng bản phát hành lớn
      Khi cài đặt, hệ thống nên tự động dùng các dependency đã được ghi lại trong lúc build
    • Có GoboLinux, và theo tôi nó giải quyết mọi thứ mà không phức tạp như Nix. Nhưng chẳng ai quan tâm

  • Đây là một trong những vấn đề lớn nhất đang níu toàn bộ nền tảng Linux lại. Người ta thường nói đó là ưu điểm, nhưng tôi không nhìn nhận như vậy
    Các nhà phát triển nêu việc có nhiều lựa chọn là điểm mạnh của Linux, nhưng với nhiều người dùng, nó trở thành nghịch lý lựa chọn và khiến họ quay lại nền tảng quen dùng trước đây
    Trên macOS và Windows có ít lựa chọn hơn, nhưng những lựa chọn khả dụng được trau chuốt hơn nhiều và ít phân mảnh hơn
    Ví dụ, ta cần bao nhiêu trình quản lý cửa sổ dạng tiling? Không thể chọn trình quản lý cửa sổ dạng tiling tốt nhất rồi làm dock và applet tốt hơn sao? Còn các ứng dụng và launcher tích hợp vào paradigm của trình quản lý cửa sổ dạng tiling thì sao?
    Thay vào đó, thường chỉ còn lại 10 loại trình quản lý cửa sổ dạng tiling và những chương trình workaround nửa vời đặt lên trên chúng

    • Người ta không phân tích exhaustive mọi lựa chọn rồi mới chọn. Họ xem một số ít ứng viên rồi chọn dùng một cái dựa trên độ phổ biến hoặc mức dễ tiếp cận
      Một hệ sinh thái thành công là hệ sinh thái cho ra kết quả đủ tốt ngay cả khi chọn những lựa chọn dễ thấy
      Việc số lượng bản phân phối Linux tăng lên phần lớn chỉ là các khác biệt nhỏ không làm giảm đáng kể mức độ phù hợp có ý nghĩa, và chỉ một số rất ít người vốn không gặp khó khăn gì khi chọn distro mới coi đó là vấn đề
      Ngược lại, những trường hợp như Wayland là vấn đề thực sự, vì phần plumbing và phần cứng bỗng trở nên quan trọng, và muốn chọn tổ hợp dùng được thì phải biết phần nào cấu trúc bên trong
      So sánh Mac hay Windows với Linux cũng không có nhiều ý nghĩa. Với 95% người tiêu dùng, hệ điều hành là một đặc tính cố định hoặc một chức năng của máy tính, chứ không phải một sản phẩm riêng
      Nếu toàn bộ gói phù hợp thì họ có thể mua một chiếc máy tính cài sẵn hệ điều hành đó, chứ không cố cài riêng lên thiết bị Windows hay Mac của mình
      Những người có đủ kiến thức kỹ thuật để hài lòng có lẽ cũng không quá bối rối nếu có thêm 3 bản phái sinh Ubuntu và 2 bản phái sinh Arch
    • Làm trình quản lý cửa sổ dạng tiling rất vui. Làm phần mềm theo kiểu cộng tác không chỉ là phương tiện để có được một sản phẩm nào đó, mà bản thân nó cũng là mục đích
      Trở thành lập trình viên mã nguồn mở nghĩa là có thể tự đặt ra mục tiêu và phương tiện cho mình, và trong phát triển phần mềm thương mại thì thường không có sự tự do đó
      Sẽ có những chỗ thô ráp, nhưng hiệu ứng IKEA sẽ phát huy tác dụng và cuối cùng bạn sẽ thích nó
    • Đây là lĩnh vực mà các bản phân phối phải giải quyết. Ai không muốn có nhiều lựa chọn thì có thể dùng một bản phân phối thay họ đưa ra nhiều quyết định, chứ không cần thúc ép loại bỏ lựa chọn khỏi toàn bộ hệ sinh thái
      Nếu tất cả dùng cùng một phần mềm, ta sẽ có một hệ sinh thái độc canh dễ bị tấn công hơn. Windows từng là mục tiêu của rất nhiều virus cũng vì mục tiêu vừa lớn vừa nhất quán
      Nếu xâm nhập được máy Windows của một người dùng phổ thông thì có thể xâm nhập những máy còn lại theo cách tương tự. Nhắm vào Linux thì khó hơn nhiều
      Hơn nữa, đây là phần mềm tự do. Nếu không phải trả tiền thuê ai đó làm, thì phần lớn là hoạt động tình nguyện, và chúng ta không thể bảo người khác phải dùng thời gian tình nguyện của họ vào việc gì
      Nếu có nhiều nhóm như vậy mà vẫn không ai muốn tham gia, thì cũng nên xem lại các cấu trúc xã hội đang chi phối. Có thể điểm khởi đầu là loại bỏ các bộ quy tắc ứng xử cho phép trừng phạt cả hành vi bên ngoài dự án
    • Tôi nghĩ launcher và dock còn nhiều hơn cả trình quản lý cửa sổ dạng tiling
      Và tôi cũng không rõ còn cần cải thiện gì thêm. Những thứ như Ulauncher hay Albert mạnh hơn nhiều so với những gì có thể làm trên các nền tảng khác, và tôi cũng không biết có thể làm UI tốt hơn nữa bằng cách nào
    • Có bao nhiêu trình quản lý cửa sổ dạng tiling cũng được, miễn là nhiều bằng số mà mọi người muốn làm

  • Việc có thêm nhiều phần mềm là điều tốt. Nhưng trước khi làm lại từ đầu, có lẽ nên cân nhắc đóng góp cho những thứ đã tồn tại, hoặc chọn các dự án đã bị bỏ rơi hay cần được chỉnh sửa để có thể build/chạy trên compiler và phần cứng mới nhất
    Tôi cũng tò mò liệu có cơ sở dữ liệu các dự án đang ngủ đông/đã chết nào đó đáng để hồi sinh không

    • Có thể một thứ đã tồn tại không được xây dựng theo cách tôi hướng tới
      Một dự án khác có thể do một người khó làm việc cùng dẫn dắt, hoặc là một cộng đồng không chấp nhận đề xuất và patch
      Các quy trình xã hội và điểm nghẽn có thể làm mất động lực đóng góp. Không phải ai cũng có thể trở thành một người chơi đội nhóm lạc quan không cá tính
      Với tôi, bắt đầu lại từ đầu thì tốt hơn. Vì tôi có thể kiểm soát mọi biến số, không cần động vào hạ tầng xã hội/kỹ thuật hiện có, không phải thuyết phục ai đó rằng ý tưởng của mình là tốt, và không muốn dành nhiều thời gian cho tranh luận, thảo luận hơn là viết code
      Trải nghiệm phát triển solo tốt hơn. Vì không bị trói buộc bởi chính trị và quy trình xã hội, còn việc thử làm người chơi đội nhóm chỉ đem lại đau khổ cho tôi
    • Trong hầu hết lĩnh vực có quá nhiều nỗ lực chất lượng thấp, và nếu gom công sức đó vào vài dự án hàng đầu thì có thể tạo ra vài ứng dụng xuất sắc
      Cộng tác có thể trông như gánh nặng và khó khăn, nhưng rốt cuộc đó là việc tạo ra kết quả, và là thời gian được dùng tốt hơn so với đổ vào một dự án rồi sẽ bị bỏ rơi
    • Tôi tò mò liệu trong các kho package Linux lớn có nơi nào thu thập thống kê để có thể tìm các ứng dụng được dùng nhiều nhưng không được bảo trì hoặc tính năng còn dang dở không

  • Có nhiều lời phàn nàn rằng thiếu công cụ để tạo ứng dụng tương thích trên nhiều hệ điều hành, nhưng tôi không đồng ý. Chỉ xét các giải pháp không phải Electron cũng đã có rồi
    Telegram dùng Qt để phân phối ứng dụng native hiệu năng tốt trên cả ba hệ điều hành
    Flutter được compile thành code native trên cả ba hệ điều hành và mobile
    Kirigami là framework QtQuick, cho phép tạo ứng dụng chạy được cho cả mục tiêu mobile lẫn desktop
    Cứ làm ứng dụng thôi. Không có lý do gì lấy chuyện này làm cái cớ để chỉ trích Linux

    • Flutter hoạt động hơi khác nhau trên từng nền tảng, nên mang lại trải nghiệm hơi kém một cách tinh vi trên mọi nền tảng. Kirigami hay Qt Quick cũng khó có thể xem là lựa chọn khả thi trên thực tế
      Trên Windows, macOS và mobile hầu như không có cộng đồng hay dự án nghiêm túc nào. Tôi không có ý hạ thấp phía KDE, nhưng thực tế là vậy
      License của Qt Quick trên iOS cũng không dễ, hoặc nếu đi theo hướng thương mại thì rất đắt
      Ngược lại, Electron được các tập đoàn lớn đầu tư và đưa ra công cụ cấp production rất được trau chuốt, có cộng đồng và hệ sinh thái thư viện khổng lồ, lại không phải một ngôn ngữ xa lạ như Dart
      Telegram thực sự đã nỗ lực hơn một bậc. Client của họ rất tuyệt
    • Ứng dụng Telegram dựa trên Qt cũng chạy tốt trên macOS, nhưng đa số người dùng Apple chọn client Swift/Cocoa cho macOS và iOS[0]
      [0]: https://github.com/overtake/TelegramSwift

  • Vấn đề là phần mềm OSS thậm chí cũng không thật sự cố gắng cạnh tranh với thị trường
    Những người dùng phần mềm OSS mặc nhiên chấp nhận rằng UX sẽ thiếu sót, và thực tế nhiều khi đúng là như vậy
    Phần mềm độc quyền thông thường phải thích nghi để làm trải nghiệm người dùng cuối tốt hơn vì có rủi ro người dùng không trả tiền, nhưng OSS thường không có rủi ro đó. Mã nguồn mở cũng cần được đặt trước những rủi ro đến từ người dùng cuối
    Tôi đã cố thay đổi điều đó bằng Notes[1], nhưng nhận ra rằng chỉ sống bằng quảng cáo thì rất khó. Tôi cũng đã thử thêm thanh toán cho các tính năng premium như Kanban, nhưng vì ứng dụng là FOSS hoàn toàn nên ai cũng có thể dễ dàng biên dịch từ mã nguồn
    Ứng dụng tiếp theo[2] tôi định chuyển sang mã nguồn đóng trước khi ra mắt. Tôi không thể chấp nhận rủi ro công sức của mình không được đền đáp
    Tôi tin rằng nếu có thể thu tiền, tôi sẽ đầu tư nhiều hơn vào các ứng dụng tập trung vào UX trên Linux, nên điều đó cũng có lợi cho cộng đồng Linux. Một phần có thể được phát hành mã nguồn mở, và trong tương lai xa có thể toàn bộ cũng sẽ được mở
    [1] https://github.com/nuttyartist/notes
    [2] https://www.get-plume.com

    • Tập giao giữa người dùng Linux và những người coi trọng tự do là rất lớn. Với nhiều người, một ứng dụng ghi chú không mã nguồn mở ngay từ đầu đã không phải là lựa chọn vì vấn đề phụ thuộc nhà cung cấp và quyền riêng tư
      Vì vậy, nếu không làm chương trình thành mã nguồn mở, bạn có khả năng mất nhiều hơn so với việc làm mã nguồn mở và chấp nhận rủi ro một số người không trả tiền
      Tôi nghĩ số người sẵn sàng trả tiền để dùng mã nguồn mở sẽ lớn hơn rất nhiều so với số người muốn dùng phần mềm độc quyền
      Mã nguồn mở không có nghĩa là phải phân phối mã cho tất cả mọi người; nếu thu tiền, bạn cũng có thể chỉ cung cấp mã nguồn cho người dùng trả phí. Tuy nhiên, họ sẽ có quyền sửa đổi và phân phối lại
      Nếu không quan tâm đến mã nguồn mở thì có thể dùng Notion hoặc Evernote. Nếu đang tìm một ứng dụng ghi chú mã nguồn mở hiện đại, tôi khuyên dùng Logseq
    • Có vẻ như bạn đang đưa ra quyết định đúng. Kiếm đủ tiền sinh sống bằng mã nguồn mở là cực kỳ khó, và quy mô nhỏ hơn nhiều bậc so với những người sống bằng phần mềm thương mại
    • Tôi hiểu sự bức xúc, nhưng cũng có phản例. Tôi không có ý hạ thấp
      Thứ nhất, Notes trông khá giống Standard Notes. Nếu bạn đã dùng OSS copyleft để tạo ra Notes, tôi nghĩ sẽ khó phàn nàn trừ khi bạn trả tiền bản quyền cho công sức của các lập trình viên khác được đưa vào đó
      Thứ hai, có lẽ tôi là một người dùng không điển hình. Tôi đã dùng Linux hơn 20 năm nhưng vẫn không viết nổi một script Bash hay một dòng Perl cho đàng hoàng
      Nhưng vì tôi không biết lập trình và biết ơn công sức của người khác cũng như sự tự do mà nó mang lại, tôi đã chi nhiều tiền cho phần mềm hơn hẳn mức cá nhân thường chi trên các nền tảng khác
      Tôi hỗ trợ nhiều nơi như Kaisen và Debian, các tiện ích cốt lõi của FSF và Emacs, KDE, Firefox của Mozilla, Betterbird, Syncthing, LaGrange, Joplin, ClipTo, SoulSeek và các dịch vụ như envs.net
      Có khoản tôi đóng hằng năm, có khoản hằng tháng, có khoản chỉ một lần
      Khi Standard Notes mới ra mắt tôi cũng đã trả tiền gói đăng ký 7 năm, nhưng dùng khoảng hai tháng rồi bỏ vì không hài lòng. Có những thứ tôi dùng nhiều như Alacritty nhưng không tìm được cách quyên góp, và tôi cố giảm thiểu những trường hợp như vậy
    • Cá nhân tôi thấy KDE vượt xa macOS và Windows
      Thật ra tôi cảm giác macOS là một trong những trình quản lý cửa sổ tệ nhất trong các nền tảng phổ biến. Nó đẹp và dễ dùng, nhưng nếu muốn làm gì vượt quá mức cơ bản thì cần những câu thần chú không thể tự nhiên phát hiện ra
      Dĩ nhiên mỗi người có gu riêng
    • Tôi có vài suy nghĩ. Dù khá theo dõi lĩnh vực này, tôi chưa từng nghe về ứng dụng đó, và mức độ cạnh tranh thì cực kỳ khốc liệt
      Tôi bấm vào xem giá premium; nếu tính theo năm thì hợp lý, nhưng chỉ thấy tùy chọn đăng ký theo tháng nên cảm thấy khó chấp nhận
      Với loại ứng dụng này, tôi có khả năng quyên góp hơn là trả tiền cho bản premium. Obsidian đã vận hành tốt với mô hình đó
      Tôi không nghĩ quyền truy cập sớm vào tính năng có giá trị lớn, nhưng có nhiều người đã trả tiền để ủng hộ công việc phát triển
      Ngoài ra, tôi nghĩ cấu trúc có một hệ sinh thái mã nguồn mở lớn xung quanh một sản phẩm lõi đóng sẽ tạo ra lý do để mọi người trả tiền

  • Giá mà bài viết có vài ví dụ thì tốt hơn
    Tôi không dễ nghĩ ra ai đang làm distro trong khi thật ra nên làm ứng dụng. Cố gượng thì có lẽ LinuxCNC? Nhưng cái đó có yêu cầu kernel cụ thể nên một distro tùy chỉnh có khi lại phù hợp hơn

    • Môi trường desktop về cơ bản là một ứng dụng có thể cài dễ dàng bằng một hai cú nhấp hoặc một lệnh
      Tôi không thật sự hiểu việc một distro phái sinh của phái sinh chỉ được phát hành kèm một môi trường desktop khác

  • Thay vì nói “Đừng làm distro Linux nữa, hãy làm ứng dụng”, tôi nghĩ tốt hơn là ngừng nghe những người muốn chỉ đạo người khác nên làm gì và không nên làm gì

    • Tôi cũng thấy khó chịu với giọng điệu đó
      Dù vậy, bản thân thông điệp và thông tin thì tốt
      Cá nhân tôi có lẽ sẽ nói kiểu “Người dùng Linux không muốn thêm distro nữa. Họ muốn phần mềm”. Ít nhất là với tôi thì vậy
    • Cũng nên ngừng nghe lời những người bảo hãy ngừng nghe những người muốn chỉ đạo người khác nên làm gì và không nên làm gì. Không phải mọi thứ đều tương đối; vẫn có lựa chọn tốt và lựa chọn xấu

  • Gần đây tôi đã chuyển từ Mac sang Linux, vì muốn dùng một thiết bị cũ hiệu năng tốt làm máy dùng hằng ngày
    Trước đây tôi cũng từng cài Linux trên nhiều máy, nhưng lần này không chỉ là sở thích đơn thuần
    Ubuntu hỗ trợ tốt phần cứng và thiết bị ngoại vi của tôi, nhưng app store thì chưa hoàn thiện và có cảm giác bị nhồi nhét gượng ép. Dù vậy, hầu như mọi thứ đều hoạt động đúng như kỳ vọng
    Tôi cũng muốn thử Mint, Debian, Arch, nhưng hơi thận trọng vì có vẻ nhiều phần mềm được viết với Ubuntu trong đầu

    • Linux Mint dựa trên Ubuntu nên có thể dùng các gói Ubuntu mà không gặp vấn đề. Thực tế có thể xem nó như một Ubuntu tốt hơn
      Cũng có phiên bản Mint dựa trên Debian, nhưng nó gần giống một phương án dự phòng để không phụ thuộc quá chí mạng vào phía Ubuntu
      Dạo này, ngay cả khi dùng một bản phân phối khác lạ cũng không phải vấn đề lớn. Vì nếu trình quản lý gói mặc định không cung cấp ứng dụng bạn muốn, bạn có thể dùng AppImage, Flatpak, Snap
    • Trong những thứ được viết cho Ubuntu, gần như không có gì có khả năng không chạy được trên Arch hay phần lớn các bản phân phối hiện đại
      Khi dùng Arch, tôi cần làm quen với những giả định của mọi người dựa trên Ubuntu, nhưng phần lớn chỉ là vá các tệp cấu hình hoặc đặt biến môi trường
      Những thứ đó là kỹ năng hữu ích và có thể mang sang dùng ở nơi khác
    • Fedora cũng rất đáng để thử một lần
      Tôi nghĩ giá mà mình đã thử nó sớm hơn

  • Không hiểu vì sao ai đó lại làm vậy. Khó hơn, và người dùng Linux sẽ không trả tiền cho những thứ không đáng để trả tiền

    • Vì thế giới sẽ được lợi nếu có thêm nhiều phần mềm miễn phí tốt