Cái gì khác: gói ứng dụng Haiku?

Cái gì khác: gói ứng dụng Haiku?

TL; DR: Haiku có thể nhận được sự hỗ trợ phù hợp cho các gói ứng dụng, chẳng hạn như thư mục ứng dụng (như .app trên Mac) và/hoặc hình ảnh ứng dụng (Linux AppImage)? Tôi nghĩ đây sẽ là một sự bổ sung đáng giá, dễ triển khai chính xác hơn các hệ thống khác vì hầu hết cơ sở hạ tầng đã có sẵn.

Một tuần trước Tôi phát hiện ra Haiku, một hệ thống tốt đến không ngờ. Chà, vì từ lâu tôi đã quan tâm đến các thư mục và hình ảnh ứng dụng (lấy cảm hứng từ sự đơn giản của Macintosh), nên không có gì ngạc nhiên khi tôi nảy ra một ý tưởng...

Để hiểu đầy đủ, tôi là người sáng tạo và tác giả của AppImage, một định dạng phân phối ứng dụng Linux nhằm mục đích đơn giản hóa Mac và trao toàn quyền kiểm soát cho các tác giả ứng dụng và người dùng cuối (nếu bạn muốn biết thêm, hãy xem wiki и tài liệu).

Điều gì sẽ xảy ra nếu chúng ta tạo AppImage cho Haiku?

Chúng ta hãy suy nghĩ một chút, hoàn toàn về mặt lý thuyết: cần phải làm gì để có được AppImage, hoặc thứ gì đó tương tự, trên Haiku? Không cần thiết phải tạo ra thứ gì đó ngay bây giờ, bởi vì hệ thống đã tồn tại ở Haiku hoạt động rất đáng kinh ngạc, nhưng một thử nghiệm tưởng tượng sẽ rất tuyệt. Nó cũng thể hiện sự tinh tế của Haiku, so với môi trường máy tính để bàn Linux, nơi mà những thứ như vậy cực kỳ khó khăn (tôi có quyền nói như vậy: Tôi đã vật lộn với việc gỡ lỗi trong 10 năm).

Cái gì khác: gói ứng dụng Haiku?
Trên Macintosh System 1, mỗi ứng dụng là một tệp riêng biệt được "quản lý" trong Finder. Sử dụng AppImage Tôi đang cố gắng tạo lại trải nghiệm người dùng tương tự trên Linux.

Đầu tiên, AppImage là gì? Đây là một hệ thống phát hành các ứng dụng của bên thứ ba (ví dụ: Ultimaker Cure), cho phép các ứng dụng được phát hành khi nào và như thế nào chúng muốn: không cần biết chi tiết cụ thể về các bản phân phối khác nhau, xây dựng chính sách hoặc xây dựng cơ sở hạ tầng, không cần hỗ trợ của người bảo trì và chúng không cho người dùng biết những gì (không) họ có thể cài đặt trên máy tính của họ. AppImage nên được hiểu là một cái gì đó tương tự như gói Mac ở định dạng .app bên trong hình ảnh đĩa .dmg. Sự khác biệt chính là các ứng dụng không được sao chép mà tồn tại mãi mãi trong AppImage, giống như các gói Haiku .hpkg được gắn và không bao giờ được cài đặt theo nghĩa thông thường.

Trong hơn 10 năm tồn tại, AppImage đã đạt được một số sự hấp dẫn và phổ biến: Bản thân Linus Torvalds đã công khai xác nhận nó và các dự án chung (ví dụ: LibreOffice, Krita, Inkscape, Scribus, ImageMagick) đã áp dụng nó làm phương pháp chính để phân phối các bản dựng liên tục hoặc hàng đêm, không can thiệp vào các ứng dụng người dùng đã cài đặt hoặc gỡ cài đặt. Tuy nhiên, các môi trường và bản phân phối máy tính để bàn Linux thường vẫn bám vào mô hình phân phối dựa trên người bảo trì tập trung, truyền thống và/hoặc quảng bá các chương trình kinh doanh và/hoặc kỹ thuật doanh nghiệp của riêng họ dựa trên Flatpak (RedHat, Fedora, Gnome) và Snappy (Chính tắc, Ubuntu). Nó đến một cách lố bịch.

Làm thế nào nó hoạt động

  • Mỗi AppImage chứa 2 phần: một ELF nhấp đúp nhỏ (được gọi là. runtime.c), theo sau là hình ảnh hệ thống tệp Bí đaoFS.

Cái gì khác: gói ứng dụng Haiku?

  • Hệ thống tệp SquashFS chứa tải trọng của ứng dụng và mọi thứ cần thiết để chạy nó, theo suy nghĩ đúng đắn, điều này không thể được coi là một phần của cài đặt mặc định cho mọi hệ thống mục tiêu khá gần đây (bản phân phối Linux). Nó cũng chứa siêu dữ liệu, chẳng hạn như tên ứng dụng, biểu tượng, loại MIME, v.v., v.v.

Cái gì khác: gói ứng dụng Haiku?

  • Khi được người dùng chạy, thời gian chạy sẽ sử dụng FUSE và Squashfuse để gắn hệ thống tệp, sau đó xử lý việc chạy một số điểm nhập (còn gọi là AppRun) bên trong AppImage được gắn.
    Hệ thống tập tin được ngắt kết nối sau khi quá trình hoàn tất.

Mọi thứ dường như trở nên đơn giản.

Và những điều này làm phức tạp mọi thứ:

  • Với nhiều bản phân phối Linux như vậy, không có gì “có suy nghĩ đúng đắn” có thể được gọi là “một phần của cài đặt mặc định cho mọi hệ thống mục tiêu mới”. Chúng tôi giải quyết vấn đề này bằng cách xây dựng danh sách loại trừ, cho phép bạn xác định những gì sẽ được đóng gói trong AppImage và những gì sẽ cần được mang đi nơi khác. Đồng thời, đôi khi chúng ta bỏ lỡ, mặc dù thực tế là nhìn chung mọi thứ đều hoạt động tốt. Vì lý do này, chúng tôi khuyên người tạo gói nên thử nghiệm AppImages trên tất cả các hệ thống đích (bản phân phối).
  • Tải trọng ứng dụng phải có thể định vị lại được trên hệ thống tệp. Thật không may, nhiều ứng dụng có đường dẫn tuyệt đối được mã hóa cứng tới các tài nguyên trong /usr/share. Điều này cần phải được khắc phục bằng cách nào đó. Ngoài ra, bạn phải xuất LD_LIBRARY_PATH, hoặc sửa rpath để trình tải có thể tìm thấy các thư viện liên quan. Phương pháp đầu tiên có nhược điểm (được khắc phục bằng những cách phức tạp) và phương pháp thứ hai đơn giản là cồng kềnh.
  • Cạm bẫy UX lớn nhất đối với người dùng là đặt bit thực thi Tệp AppImage sau khi tải xuống. Dù bạn có tin hay không, đây thực sự là một rào cản đối với một số người. Yêu cầu thiết lập bit khả năng thực thi là phức tạp ngay cả đối với người dùng có kinh nghiệm. Để giải quyết vấn đề này, chúng tôi khuyên bạn nên cài đặt một dịch vụ nhỏ giám sát các tệp AppImage và đặt bit khả năng thực thi của chúng. Ở dạng nguyên chất, nó không phải là giải pháp tốt nhất vì nó sẽ không hoạt động tốt. Các bản phân phối Linux không cung cấp dịch vụ này, do đó, người dùng có trải nghiệm không tốt.
  • Người dùng Linux mong đợi một ứng dụng mới có biểu tượng trong menu khởi động. Bạn không thể nói với hệ thống: “Nhìn này, có một ứng dụng mới, hãy làm việc thôi.” Thay vào đó, theo đặc tả XDG, bạn cần sao chép tệp .desktop đến đúng nơi trong /usr để cài đặt trên toàn hệ thống hoặc trong $HOME dành cho cá nhân. Các biểu tượng có kích thước nhất định, theo đặc tả XDG, cần được đặt ở những vị trí nhất định trong usr hoặc $HOME, sau đó chạy các lệnh trong môi trường làm việc để cập nhật bộ đệm biểu tượng hoặc hy vọng rằng trình quản lý môi trường làm việc sẽ tìm ra và tự động phát hiện mọi thứ. Tương tự với các loại MIME. Để giải quyết vấn đề này, người ta đề xuất sử dụng cùng một dịch vụ, ngoài việc đặt cờ khả năng thực thi, nếu có biểu tượng, v.v. trong AppImage, sao chép chúng từ AppImage vào đúng vị trí theo XDG. Khi bị xóa hoặc di chuyển, dịch vụ sẽ xóa mọi thứ. Tất nhiên, có sự khác biệt trong hoạt động của từng môi trường làm việc, về định dạng tệp đồ họa, kích thước, vị trí lưu trữ và phương pháp cập nhật bộ đệm, điều này gây ra sự cố. Nói tóm lại, phương pháp này là một cái nạng.
  • Nếu cách trên vẫn chưa đủ thì vẫn không có biểu tượng AppImage trong trình quản lý tệp. Thế giới Linux vẫn chưa quyết định triển khai elficon (mặc dù thảo luận и thực hiện), nên không thể nhúng trực tiếp biểu tượng vào ứng dụng. Vì vậy, hóa ra các ứng dụng trong trình quản lý tệp không có biểu tượng riêng (không có sự khác biệt, AppImage hay thứ gì khác), chúng chỉ có trong menu bắt đầu. Để giải quyết vấn đề này, chúng tôi đang sử dụng hình thu nhỏ, một cơ chế ban đầu được thiết kế để cho phép người quản lý máy tính để bàn hiển thị hình ảnh xem trước hình thu nhỏ của tệp đồ họa dưới dạng biểu tượng của chúng. Do đó, dịch vụ thiết lập bit thực thi cũng hoạt động như một “công cụ thu nhỏ”, tạo và ghi hình thu nhỏ của biểu tượng vào các vị trí thích hợp /usr и $HOME. Dịch vụ này cũng thực hiện dọn dẹp nếu AppImage bị xóa hoặc di chuyển. Do thực tế là mỗi trình quản lý máy tính để bàn hoạt động hơi khác nhau, chẳng hạn như nó chấp nhận biểu tượng ở định dạng nào, kích thước hoặc vị trí như thế nào, tất cả đều thực sự khó khăn.
  • Ứng dụng chỉ gặp sự cố khi thực thi nếu xảy ra lỗi (ví dụ: có một thư viện không phải là một phần của hệ thống cơ sở và không được cung cấp trong AppImage) và không ai cho người dùng trong GUI biết chính xác điều gì đang xảy ra. Chúng tôi bắt đầu giải quyết vấn đề này bằng cách sử dụng thông báo trên màn hình nền, nghĩa là chúng ta cần phát hiện lỗi từ dòng lệnh, chuyển chúng thành thông báo mà người dùng hiểu được, sau đó cần hiển thị trên màn hình nền. Và tất nhiên, mỗi môi trường máy tính để bàn xử lý chúng hơi khác một chút.
  • Hiện tại (tháng 2019 năm XNUMX - ghi chú của người dịch) tôi chưa tìm được cách đơn giản nào để thông báo cho hệ thống rằng tệp 1.png phải được mở bằng Krita và 2.png - sử dụng GIMP.

Cái gì khác: gói ứng dụng Haiku?
Vị trí lưu trữ các thông số kỹ thuật dành cho nhiều máy tính được sử dụng trong GNOME, KDE и Xfce là freedesktop.org

Đạt được mức độ tinh tế gắn chặt với môi trường làm việc Haiku là điều khó khăn, nếu không muốn nói là không thể, do các thông số kỹ thuật XDG từ freedesktop.org dành cho nhiều máy tính để bàn cũng như việc triển khai các trình quản lý máy tính để bàn dựa trên các thông số kỹ thuật này. Để làm ví dụ, chúng ta có thể trích dẫn một biểu tượng Firefox trên toàn hệ thống: rõ ràng, các tác giả của XDG thậm chí không nghĩ rằng một người dùng có thể cài đặt nhiều phiên bản của cùng một ứng dụng.

Cái gì khác: gói ứng dụng Haiku?
Biểu tượng cho các phiên bản Firefox khác nhau

Tôi đang tự hỏi thế giới Linux có thể học được gì từ Mac OS X để tránh làm hỏng việc tích hợp hệ thống. Nếu bạn có thời gian và quan tâm đến vấn đề này, hãy nhớ đọc những gì Arnaud Gurdol, một trong những kỹ sư Mac OS X đầu tiên, đã nói:

Chúng tôi muốn cài đặt ứng dụng dễ dàng như kéo biểu tượng ứng dụng từ đâu đó (máy chủ, ổ đĩa ngoài) vào ổ đĩa máy tính của bạn. Để thực hiện điều này, gói ứng dụng lưu trữ tất cả thông tin, bao gồm biểu tượng, phiên bản, loại tệp đang được xử lý, loại lược đồ URL mà hệ thống cần biết để xử lý ứng dụng. Điều này cũng bao gồm thông tin về 'bộ lưu trữ trung tâm' trong cơ sở dữ liệu Dịch vụ biểu tượng và Dịch vụ khởi chạy. Để hỗ trợ hiệu suất, các ứng dụng được 'phát hiện' ở một số vị trí 'nổi tiếng': thư mục Ứng dụng của hệ thống và người dùng và một số thư mục khác một cách tự động nếu người dùng điều hướng đến Finder trong thư mục chứa ứng dụng. Trong thực tế, điều này hoạt động rất tốt.

https://youtu.be/qQsnqWJ8D2c
Apple WWDC 2000 phiên 144 - Mac OS X: đóng gói ứng dụng và in ấn tài liệu.

Không có cơ sở hạ tầng nào giống như cơ sở hạ tầng này trên máy tính để bàn Linux, vì vậy chúng tôi đang tìm cách giải quyết xung quanh những hạn chế về cấu trúc trong dự án AppImage.

Cái gì khác: gói ứng dụng Haiku?
Haiku có đến giải cứu không?

Và một điều nữa: Các nền tảng Linux làm nền tảng cho môi trường máy tính để bàn có xu hướng không được xác định rõ ràng đến mức nhiều thứ khá đơn giản trong một hệ thống full-stack nhất quán lại bị phân mảnh và phức tạp một cách khó chịu trong Linux. Tôi đã dành toàn bộ báo cáo về các vấn đề liên quan đến nền tảng Linux dành cho môi trường máy tính để bàn (các nhà phát triển am hiểu đã xác nhận rằng mọi thứ sẽ vẫn như vậy trong một thời gian rất dài).

Báo cáo của tôi về các vấn đề của môi trường máy tính để bàn Linux năm 2018

Ngay cả Linus Torvalds cũng thừa nhận rằng sự phân mảnh là nguyên nhân khiến ý tưởng về không gian làm việc thất bại.

Rất vui được gặp Haiku!

Haiku khiến mọi thứ trở nên đơn giản đến kinh ngạc

Mặc dù cách tiếp cận ngây thơ để "chuyển" AppImage sang Haiku chỉ đơn giản là cố gắng xây dựng (chủ yếu là run.c và dịch vụ) các thành phần của nó (thậm chí có thể thực hiện được!), nhưng điều này sẽ không mang lại nhiều lợi ích cho Haiku. Bởi vì trên thực tế, hầu hết những vấn đề này đều được giải quyết bằng thơ Haiku và đúng đắn về mặt khái niệm. Haiku cung cấp chính xác các khối xây dựng cơ sở hạ tầng hệ thống mà tôi đã tìm kiếm trong môi trường máy tính để bàn Linux bấy lâu nay và không thể tin được là không có ở đó. Cụ thể là:

Cái gì khác: gói ứng dụng Haiku?
Dù bạn có tin hay không, đây là điều mà nhiều người dùng Linux không thể vượt qua. Trên Haiku mọi thứ đều được thực hiện tự động!

  • Các tệp ELF không có bit thực thi sẽ tự động nhận được một bit khi nhấp đúp vào trình quản lý tệp.
  • Các ứng dụng có thể có các tài nguyên tích hợp sẵn, chẳng hạn như các biểu tượng, được hiển thị trong trình quản lý tệp. Không cần phải sao chép một loạt hình ảnh vào các thư mục đặc biệt có biểu tượng và do đó không cần phải dọn sạch chúng sau khi xóa hoặc di chuyển ứng dụng.
  • Có cơ sở dữ liệu để liên kết ứng dụng với tài liệu, việc này không cần sao chép bất kỳ tệp nào.
  • Trong thư mục lib/ bên cạnh tệp thi hành, các thư viện được tìm kiếm theo mặc định.
  • Không có nhiều bản phân phối và môi trường máy tính để bàn; bất cứ thứ gì hoạt động, đều hoạt động ở mọi nơi.
  • Không có mô-đun riêng biệt nào để chạy khác với thư mục Ứng dụng.
  • Các ứng dụng không có sẵn đường dẫn tuyệt đối đến tài nguyên của chúng; chúng có các chức năng đặc biệt để xác định vị trí trong thời gian chạy.
  • Ý tưởng về hình ảnh hệ thống tệp nén đã được giới thiệu: đây là gói hpkg bất kỳ. Tất cả chúng đều được gắn bởi kernel.
  • Mỗi tệp được mở bởi ứng dụng đã tạo ra nó, trừ khi bạn chỉ định rõ ràng khác. Thật tuyệt!

Cái gì khác: gói ứng dụng Haiku?
Hai tập tin png. Lưu ý các biểu tượng khác nhau cho biết chúng sẽ được mở bởi các ứng dụng khác nhau khi nhấp đúp. Cũng lưu ý menu thả xuống "Mở bằng:" nơi người dùng có thể chọn một ứng dụng riêng lẻ. Thật đơn giản!

Có vẻ như nhiều giải pháp hỗ trợ và giải pháp mà AppImage yêu cầu trên Linux trở nên không cần thiết trên Haiku, vốn có cốt lõi là sự đơn giản và tinh tế giúp nó đáp ứng hầu hết các nhu cầu của chúng ta.

Rốt cuộc Haiku có cần gói ứng dụng không?

Điều này dẫn đến một câu hỏi lớn. Nếu việc tạo một hệ thống như AppImage trên Haiku dễ dàng hơn nhiều so với trên Linux, liệu điều đó có đáng làm không? Hay Haiku, với hệ thống gói hpkg của mình, đã loại bỏ một cách hiệu quả nhu cầu phát triển ý tưởng như vậy? Chà, để trả lời, chúng ta cần xem xét động lực đằng sau sự tồn tại của AppImages.

Quan điểm của người dùng

Hãy nhìn vào người dùng cuối của chúng tôi:

  • Tôi muốn cài đặt một ứng dụng mà không yêu cầu mật khẩu quản trị viên (root). Không có khái niệm quản trị viên trên Haiku, người dùng có toàn quyền kiểm soát vì đây là hệ thống cá nhân! (Về nguyên tắc, bạn có thể hình dung điều này ở chế độ nhiều người chơi, tôi hy vọng các nhà phát triển giữ nó đơn giản)
  • Tôi muốn tải các phiên bản ứng dụng mới nhất và tuyệt vời nhất mà không cần đợi chúng xuất hiện trong bản phân phối của mình (thường thì điều này có nghĩa là “không bao giờ”, ít nhất là trừ khi tôi cập nhật toàn bộ hệ điều hành). Trên Haiku, vấn đề này được "giải quyết" bằng các bản phát hành thả nổi. Điều này có nghĩa là có thể tải xuống các phiên bản ứng dụng mới nhất và tốt nhất, nhưng để làm được điều này, bạn cần phải cập nhật liên tục phần còn lại của hệ thống, biến nó thành “mục tiêu di động” một cách hiệu quả..
  • Tôi muốn có nhiều phiên bản của cùng một ứng dụng đặt cạnh nhau, vì không có cách nào để biết phiên bản mới nhất đã bị lỗi gì, hoặc giả sử, tôi, với tư cách là một nhà phát triển web, cần phải kiểm tra công việc của mình trong các phiên bản khác nhau của trình duyệt. Haiku giải quyết được vấn đề đầu tiên, nhưng không giải quyết được vấn đề thứ hai. Các bản cập nhật được khôi phục, nhưng chỉ cho toàn bộ hệ thống; không thể (theo như tôi biết) chạy, chẳng hạn như một số phiên bản WebPositive hoặc LibreOffice cùng một lúc.

Một trong những nhà phát triển viết:

Về cơ bản lý do cơ bản là thế này: trường hợp sử dụng rất hiếm nên việc tối ưu hóa nó không có ý nghĩa gì; coi nó như một trường hợp đặc biệt trong HaikuPorts có vẻ dễ chấp nhận hơn.

  • Tôi cần giữ các ứng dụng ở nơi tôi thích chứ không phải trên ổ đĩa khởi động của mình. Tôi thường xuyên hết dung lượng ổ đĩa nên cần kết nối ổ đĩa ngoài hoặc thư mục mạng để lưu trữ ứng dụng (tất cả các phiên bản mà tôi đã tải xuống). Nếu tôi kết nối một ổ đĩa như vậy, tôi cần khởi chạy ứng dụng bằng cách nhấp đúp. Haiku lưu các phiên bản cũ của gói, nhưng tôi không biết cách chuyển chúng sang ổ đĩa ngoài hoặc cách khởi chạy ứng dụng từ đó sau này.

Nhận xét của nhà phát triển:

Về mặt kỹ thuật, điều này đã có thể thực hiện được bằng lệnh mount. Tất nhiên, chúng tôi sẽ tạo GUI cho việc này ngay khi có đủ người dùng quan tâm.

  • Tôi không cần hàng triệu tệp nằm rải rác trên hệ thống tệp mà tôi không thể tự quản lý theo cách thủ công. Tôi muốn một tệp cho mỗi ứng dụng mà tôi có thể dễ dàng tải xuống, di chuyển, xóa. Trên Haiku vấn đề này được giải quyết bằng cách sử dụng các gói .hpkg, chẳng hạn như chuyển python từ hàng nghìn tệp thành một. Nhưng nếu có, chẳng hạn như Scribus sử dụng python, thì tôi phải xử lý ít nhất hai tệp. Và tôi phải cẩn thận để giữ cho các phiên bản của chúng hoạt động được với nhau.

Cái gì khác: gói ứng dụng Haiku?
Nhiều phiên bản AppImages chạy cạnh nhau trên cùng một Linux

Góc nhìn của nhà phát triển ứng dụng

Hãy nhìn từ quan điểm của một nhà phát triển ứng dụng:

  • Tôi muốn kiểm soát toàn bộ trải nghiệm người dùng. Tôi không muốn phụ thuộc vào hệ điều hành để cho tôi biết khi nào và bằng cách nào tôi nên phát hành ứng dụng. Haiku cho phép các nhà phát triển làm việc với kho hpkg của riêng họ, nhưng điều này có nghĩa là người dùng sẽ phải thiết lập chúng theo cách thủ công, điều này khiến ý tưởng này "kém hấp dẫn".
  • Tôi có một trang tải xuống trên trang web của mình, nơi tôi phân phối .exe cho cửa sổ, .dmg dành cho Mac và .AppImage cho Linux. Hoặc có thể tôi muốn kiếm tiền từ việc truy cập vào trang này, điều gì cũng có thể? Tôi nên đặt gì ở đó cho Haiku? Tập tin là đủ .hpkg chỉ phụ thuộc từ HaikuPorts
  • Phần mềm của tôi yêu cầu phiên bản cụ thể của phần mềm khác. Ví dụ: được biết rằng Krita yêu cầu một phiên bản vá lỗi của Qt hoặc Qt được tinh chỉnh cho phù hợp với một phiên bản cụ thể của Krita, ít nhất là cho đến khi các bản vá được đẩy trở lại Qt. Bạn có thể đóng gói Qt của riêng mình cho ứng dụng của mình trong một gói .hpkg, nhưng rất có thể điều này không được hoan nghênh.

Cái gì khác: gói ứng dụng Haiku?
Trang tải xuống ứng dụng thông thường. Tôi nên đăng gì ở đây cho Haiku?

Các gói Will (tồn tại dưới dạng thư mục ứng dụng như AppDir hoặc .app theo phong cách Apple) và/hoặc hình ảnh (ở dạng AppImages hoặc .dmg từ Apple) có phải là một bổ sung hữu ích cho môi trường máy tính để bàn Haiku không? Hay nó sẽ làm loãng đi toàn bộ bức tranh và dẫn đến sự phân mảnh, và do đó tăng thêm sự phức tạp? Tôi bị giằng xé: một mặt, vẻ đẹp và sự tinh tế của Haiku dựa trên thực tế là thường có một cách để làm một việc gì đó chứ không phải nhiều cách. Mặt khác, hầu hết cơ sở hạ tầng dành cho danh mục và/hoặc bộ ứng dụng đã có sẵn, do đó hệ thống yêu cầu một số phần trăm còn lại được đưa vào sử dụng.

Theo nhà phát triển Ông. lạch bạch

Trên Linux họ (danh mục sản phẩm và bộ ứng dụng, - khoảng. người phiên dịch) rất có thể là một giải pháp kỹ thuật cho các vấn đề mang tính hệ thống. Tại Haiku, chúng tôi thích giải quyết các vấn đề hệ thống một cách đơn giản hơn.

Bạn nghĩ sao?

Trước khi bạn trả lời...

Đợi đã, hãy kiểm tra thực tế nhanh: trên thực tế thư mục ứng dụng - đã là một phần của Haiku:

Cái gì khác: gói ứng dụng Haiku?
Thư mục ứng dụng đã tồn tại trên Haiku nhưng chưa được hỗ trợ trong trình quản lý tệp

Chúng chỉ không được hỗ trợ tốt như Macintosh Finder. Sẽ tuyệt vời biết bao nếu thư mục QtCreator có tên và biểu tượng "QtCreator" ở góc trên cùng bên trái, khởi chạy ứng dụng khi nhấp đúp vào?

Trước đó một chút tôi đã yêu cầu:

Bạn có chắc chắn rằng bạn có thể chạy các ứng dụng hàng chục năm tuổi của mình ngay hôm nay khi tất cả các cửa hàng ứng dụng và kho phân phối đã quên chúng và các phần phụ thuộc của chúng không? Bạn có tự tin rằng mình vẫn có thể tiếp cận được công việc hiện tại trong tương lai không?

Đã có câu trả lời từ Haiku chưa, hoặc các danh mục và gói ứng dụng có thể trợ giúp ở đây không? Tôi nghĩ họ có thể.

Theo ông. waddlesplash:

Có, chúng tôi có câu trả lời cho câu hỏi: chúng tôi sẽ chỉ hỗ trợ các ứng dụng này trong thời gian cần thiết cho đến khi ai đó có thể đọc định dạng tệp của chúng theo đúng cách hoặc cung cấp chức năng riêng lẻ. Cam kết hỗ trợ ứng dụng BeOS R5 trên Haiku của chúng tôi là bằng chứng cho điều này...

Chắc chắn rồi!

Haiku nên thực hiện hành động nào?

Tôi có thể tưởng tượng sự chung sống hòa bình của hpkg, thư mục và hình ảnh ứng dụng:

  • Sử dụng phần mềm hệ thống .hpkg
  • Đối với phần mềm được sử dụng thường xuyên nhất (đặc biệt là những phần mềm cần lên lịch phát hành), hãy sử dụng .hpkg (khoảng 80% các trường hợp)
  • Một số được cài đặt qua .hpkg, các ứng dụng sẽ được hưởng lợi từ việc chuyển sang cơ sở hạ tầng thư mục ứng dụng (ví dụ QtCreator): chúng sẽ được phân phối dưới dạng .hpkg, như trước.

Ông. waddlesplash viết:

Nếu tất cả những gì bạn cần là xem các ứng dụng trong /system/apps, thay vào đó chúng ta nên làm cho các thư mục trong Deskbar dễ quản lý hơn đối với người dùng, vì /system/apps không nhằm mục đích để người dùng mở và xem thường xuyên (không giống như MacOS). Đối với những tình huống như vậy, Haiku có một mô hình khác, nhưng về mặt lý thuyết, lựa chọn này có thể chấp nhận được.

  • Haiku nhận được cơ sở hạ tầng để chạy hình ảnh ứng dụng, các bản dựng phần mềm hàng đêm, liên tục và thử nghiệm, cũng như cho các trường hợp người dùng muốn “đóng băng kịp thời”, đối với phần mềm riêng tư và nội bộ cũng như các trường hợp sử dụng đặc biệt khác (khoảng 20% của tất cả). Những hình ảnh này chứa các tập tin cần thiết để chạy ứng dụng .hpkg, được hệ thống gắn kết và sau khi ứng dụng hoàn tất - chưa được gắn kết. (Có lẽ trình quản lý tệp có thể đặt các tệp .hpkg vào hình ảnh ứng dụng, tự động hoặc theo yêu cầu của người dùng - giống như khi bạn kéo một ứng dụng vào thư mục mạng hoặc ổ đĩa ngoài. Nó chỉ là một bài hát thôi! Hay đúng hơn là thơ - haiku.) Mặt khác, người dùng có thể muốn cài đặt nội dung của hình ảnh dưới dạng tệp.hpkg, sau đó chúng sẽ được cập nhật và xử lý theo cách tương tự như khi chúng được cài đặt thông qua HaikuDepot... Chúng ta cần phải động não).

Trích dẫn từ Mr. waddlesplash:

Việc chạy các ứng dụng từ ổ đĩa ngoài hoặc thư mục mạng có thể hữu ích. Và việc thêm khả năng định cấu hình nhiều "vùng" hơn cho pkgman chắc chắn sẽ là một tính năng hay.

Hệ thống như vậy sẽ tận dụng lợi thế của hpkg, thư mục và hình ảnh ứng dụng. Họ tốt về mặt cá nhân, nhưng cùng nhau họ sẽ trở nên bất khả chiến bại.

Kết luận

Haiku có một khung cung cấp trải nghiệm người dùng đơn giản và phức tạp cho PC, đồng thời vượt xa những gì thường được cung cấp cho PC Linux. Hệ thống trọn gói .hpkg là một ví dụ như vậy, nhưng phần còn lại của hệ thống cũng thấm đẫm sự tinh tế. Tuy nhiên, Haiku sẽ được hưởng lợi từ việc hỗ trợ hình ảnh ứng dụng và thư mục thích hợp. Cách tốt nhất để thực hiện điều này đáng để thảo luận với những người biết về Haiku, triết lý và kiến ​​trúc của nó tốt hơn tôi nhiều. Rốt cuộc, tôi đã sử dụng Haiku được hơn một tuần. Tuy nhiên, tôi tin rằng các nhà thiết kế, nhà phát triển và kiến ​​trúc sư của Haiku sẽ được hưởng lợi từ quan điểm mới mẻ này. Ít nhất, tôi sẽ rất vui khi được trở thành “đối tác đấu tập” của họ. Tôi có hơn 10 năm kinh nghiệm thực tế với các danh mục và gói ứng dụng Linux và tôi muốn tìm cách sử dụng chúng trong Haiku, nơi mà tôi nghĩ chúng hoàn toàn phù hợp. Những giải pháp tiềm năng mà tôi đề xuất không phải là những giải pháp đúng đắn duy nhất cho những vấn đề tôi đã mô tả, và nếu nhóm Haiku quyết định tìm những giải pháp khác, tao nhã hơn thì tôi hoàn toàn ủng hộ. Về cơ bản, tôi đã nghĩ đến ý tưởng làm thế nào để tạo ra một hệ thống hpkg thậm chí còn tuyệt vời hơn mà không thay đổi cách thức hoạt động. Hóa ra nhóm Haiku đã nghĩ đến các gói ứng dụng từ lâu khi triển khai hệ thống quản lý gói, nhưng thật không may (tôi nghĩ) ý tưởng này đã trở nên "lỗi thời". Có lẽ đã đến lúc phải hồi sinh nó?

Hãy tự mình thử nó! Xét cho cùng, dự án Haiku cung cấp hình ảnh để khởi động từ DVD hoặc USB, được tạo hằng ngày.
Bạn có câu hỏi nào không? Chúng tôi mời bạn đến với buổi nói chuyện bằng tiếng Nga kênh điện tín.

Tổng quan về lỗi: Cách tự bắn vào chân mình trong C và C++. Bộ sưu tập công thức hệ điều hành Haiku

Từ tác giả bản dịch: đây là bài thứ tám và cũng là bài cuối cùng trong loạt bài về Haiku.

Danh sách các bài viết: Đầu tiên Thứ hai Третья Thứ tư Thứ năm Thứ sáu thứ bảy

Chỉ những người dùng đã đăng ký mới có thể tham gia khảo sát. Đăng nhập, xin vui lòng.

Việc chuyển hệ thống hpkg sang Linux có hợp lý không?

  • vâng

  • Không

  • Đã triển khai rồi, tôi sẽ viết ở phần bình luận

20 người dùng bình chọn. 5 người dùng bỏ phiếu trắng.

Nguồn: www.habr.com

Thêm một lời nhận xét