다른 것: Haiku 앱 번들?

TL; DR: Haiku가 애플리케이션 디렉토리(예: .app Mac의 경우) 및/또는 애플리케이션 이미지(Linux의 경우) AppImage)? 대부분의 인프라가 이미 갖추어져 있으므로 다른 시스템보다 올바르게 구현하기가 더 쉬운 가치 있는 추가 기능이 될 것이라고 생각합니다.

일주일 전 의외의 좋은 시스템인 하이쿠를 발견했습니다. 글쎄요, 저는 오랫동안 디렉토리와 애플리케이션 이미지(Macintosh의 단순함에서 영감을 받은)에 관심을 가져왔기 때문에 어떤 아이디어가 떠오른 것은 놀라운 일이 아닙니다.

완전한 이해를 돕기 위해 저는 Mac 단순성을 목표로 하고 애플리케이션 작성자와 최종 사용자에게 모든 권한을 제공하는 Linux 애플리케이션 배포 형식인 AppImage의 창시자이자 작성자입니다(자세한 내용은 다음을 참조하세요). 위키 и 문서).

Haiku용 AppImage를 만들면 어떨까요?

순전히 이론적으로 조금 생각해 봅시다. AppImage, 또는 이와 유사한 것이 Haiku에 있습니까? 하이쿠에 이미 존재하는 시스템이 놀랍도록 작동하기 때문에 지금 당장 무언가를 만들 필요는 없지만 상상의 실험도 좋을 것입니다. 리눅스 데스크탑 환경에 비하면 하이쿠의 정교함도 보여준다. 그런 일이 엄청나게 어렵다(나도 그렇게 말할 권리가 있다. 나는 10년 동안 디버깅에 애썼다).

Macintosh System 1에서 각 응용 프로그램은 Finder에서 "관리되는" 별도의 파일이었습니다. AppImage를 사용하여 Linux에서 동일한 사용자 경험을 재현하려고 합니다.

먼저, AppImage란 무엇인가요? 이는 타사 애플리케이션을 출시하기 위한 시스템입니다(예: 얼티메이커 큐라), 원하는 시간과 방법으로 애플리케이션을 출시할 수 있습니다. 다양한 배포판의 세부 사항을 알 필요도 없고, 정책을 구축하거나 인프라를 구축할 필요도 없으며, 관리자 지원도 필요하지 않으며, 사용자에게 무엇을 설치할 수 있는지 알려주지 않습니다. 그들의 컴퓨터에서. AppImage는 형식 면에서 Mac 패키지와 유사한 것으로 이해되어야 합니다. .app 디스크 이미지 내부 .dmg. 주요 차이점은 애플리케이션이 복사되지 않고 Haiku 패키지와 거의 동일하게 AppImage 내부에 영원히 남아 있다는 것입니다. .hpkg 마운트되었으며 일반적인 의미로는 설치되지 않았습니다.

10년이 넘는 기간 동안 AppImage는 어느 정도 매력과 인기를 얻었습니다. Linus Torvalds 자신이 이를 공개적으로 승인했으며 일반 프로젝트(예: LibreOffice, Krita, Inkscape, Scribus, ImageMagick)에서 이를 주요 방법으로 채택했습니다. 설치 또는 제거된 사용자 애플리케이션을 방해하지 않고 연속 또는 야간 빌드를 배포합니다. 그러나 Linux 데스크탑 환경 및 배포판은 여전히 ​​전통적인 중앙 집중식 관리자 기반 배포 모델을 고수하거나 다음을 기반으로 하는 자체 엔터프라이즈 비즈니스 및/또는 엔지니어링 프로그램을 홍보하는 경우가 많습니다. 플랫 팩 (RedHat, Fedora, GNOME) 및 팔팔한 (정식, 우분투). 온다 말도 안되게.

작동 방식

• 각 AppImage에는 작은 두 번 클릭 ELF(소위. runtime.c), 그 뒤에 파일 시스템 이미지가 옵니다. 스쿼시FS.

• SquashFS 파일 시스템에는 응용 프로그램의 페이로드와 응용 프로그램을 실행하는 데 필요한 모든 것이 포함되어 있습니다. 올바른 생각으로는 모든 최신 대상 시스템(Linux 배포판)에 대한 기본 설치의 일부로 간주할 수 없습니다. 또한 애플리케이션 이름, 아이콘, MIME 유형 등과 같은 메타데이터도 포함됩니다.

• 사용자가 실행하면 런타임은 FUSE 및 squashfuse를 사용하여 파일 시스템을 마운트한 다음 마운트된 AppImage 내에서 일부 진입점(AppRun이라고도 함) 실행을 처리합니다.
  프로세스가 완료되면 파일 시스템이 마운트 해제됩니다.

모든 것이 간단해 보입니다.

그리고 이런 것들이 모든 것을 복잡하게 만듭니다.

• 이러한 다양한 Linux 배포판을 사용하면 "제대로 생각한" 것은 "모든 새 대상 시스템에 대한 기본 설치의 일부"라고 할 수 없습니다. 우리는 다음을 구축하여 이 문제를 해결합니다. 제외 목록, AppImage에 패키징할 항목과 다른 곳으로 가져가야 할 항목을 결정할 수 있습니다. 동시에, 일반적으로 모든 것이 훌륭하게 작동한다는 사실에도 불구하고 우리는 때때로 그리워합니다. 이러한 이유로 패키지 작성자는 모든 대상 시스템(배포판)에서 AppImage를 테스트하는 것이 좋습니다.
• 애플리케이션 페이로드는 파일 시스템 전체에서 재배치 가능해야 합니다. 안타깝게도 많은 애플리케이션에는 예를 들어 다음 리소스에 대한 절대 경로가 하드 코딩되어 있습니다. /usr/share. 이 문제는 어떻게든 해결되어야 합니다. 또한 다음 중 하나를 내보내야 합니다. LD_LIBRARY_PATH또는 수정 rpath 로더가 관련 라이브러리를 찾을 수 있도록 합니다. 첫 번째 방법에는 단점(복잡한 방법으로 극복됨)이 있고 두 번째 방법은 단순히 번거롭습니다.
• 사용자에게 가장 큰 UX 함정은 실행 가능 비트 설정 AppImage 파일을 다운로드한 후. 믿거나 말거나, 이는 일부 사람들에게 진정한 장벽이 됩니다. 실행 가능성 비트를 설정해야 하는 필요성은 숙련된 사용자에게도 번거롭습니다. 해결 방법으로 AppImage 파일을 모니터링하고 실행 가능성 비트를 설정하는 소규모 서비스 설치를 제안했습니다. 순수한 형태에서는 기본적으로 작동하지 않으므로 최상의 솔루션이 아닙니다. Linux 배포판은 이 서비스를 제공하지 않으므로 사용자는 처음부터 나쁜 경험을 합니다.
• Linux 사용자는 새 애플리케이션의 시작 메뉴에 아이콘이 있을 것으로 기대합니다. 시스템에 "보세요, 새로운 애플리케이션이 있습니다. 작업해 보겠습니다."라고 말할 수는 없습니다. 대신 XDG 사양에 따라 파일을 복사해야 합니다. .desktop 올바른 장소로 /usr 시스템 전체 설치의 경우 또는 $HOME 개인용. XDG 사양에 따라 특정 크기의 아이콘은 다음의 특정 위치에 배치되어야 합니다. usr 또는 $HOME그런 다음 작업 환경에서 명령을 실행하여 아이콘 캐시를 업데이트하거나 작업 환경 관리자가 이를 파악하고 모든 것을 자동으로 감지하기를 바랍니다. MIME 유형과 동일합니다. 해결 방법으로 실행 가능성 플래그 설정 외에도 아이콘 등이 있는 경우 동일한 서비스를 사용하는 것이 제안됩니다. AppImage에서는 XDG에 따라 AppImage의 올바른 위치에 복사합니다. 삭제되거나 이동되면 서비스는 모든 것을 지울 것으로 예상됩니다. 물론 각 작업 환경의 동작, 그래픽 파일 형식, 크기, 저장 위치 및 캐시 업데이트 방법에 차이가 있어 문제가 발생합니다. 간단히 말해서, 이 방법은 버팀목입니다.
• 위의 내용이 충분하지 않으면 파일 관리자에 AppImage 아이콘이 아직 없습니다. Linux 세계에서는 아직 elficon을 구현하기로 결정하지 않았습니다. обсуждение и 구현), 따라서 아이콘을 애플리케이션에 직접 삽입하는 것은 불가능합니다. 따라서 파일 관리자의 응용 프로그램에는 자체 아이콘(차이 없음, AppImage 등 없음)이 없고 시작 메뉴에만 있는 것으로 나타났습니다. 해결 방법으로 우리는 데스크톱 관리자가 그래픽 파일의 썸네일 미리 보기 이미지를 아이콘으로 표시할 수 있도록 원래 설계된 메커니즘인 썸네일을 사용하고 있습니다. 결과적으로, 실행 가능성 비트를 설정하는 서비스는 "소형화 장치"로도 작동하여 아이콘 썸네일을 생성하고 적절한 위치에 기록합니다. /usr и $HOME. 이 서비스는 AppImage가 삭제되거나 이동된 경우에도 정리를 수행합니다. 예를 들어, 아이콘을 허용하는 형식, 크기 또는 위치 등 각 데스크톱 관리자는 조금씩 다르게 동작하기 때문에 이 모든 것이 정말 고통스럽습니다.
• 오류가 발생하면 애플리케이션이 실행 시 단순히 충돌하며(예: 기본 시스템의 일부가 아니고 AppImage에 제공되지 않는 라이브러리가 있는 경우) GUI에서 정확히 무슨 일이 일어나고 있는지 사용자에게 알려주는 사람이 없습니다. 우리는 다음을 사용하여 이 문제를 해결하기 시작했습니다. 알림 즉, 명령줄에서 오류를 잡아서 사용자가 이해할 수 있는 메시지로 변환한 다음 데스크탑에 표시해야 합니다. 물론 각 데스크톱 환경에서는 이를 조금씩 다르게 처리합니다.
• 현재(2019년 XNUMX월 - 번역자의 메모) 나는 시스템에 파일이 있음을 알리는 간단한 방법을 찾지 못했습니다. 1.png Krita를 사용하여 열어야 하며, 2.png - 김프를 사용합니다.

다음에 사용되는 크로스 데스크톱 사양의 저장 위치 GNOME, KDE и Xfce freedesktop.org입니다

사양으로 인해 하이쿠 작업 환경에 깊이 스며들어 있는 정교함 수준을 달성하는 것은 불가능하지는 않더라도 어렵습니다. freedesktop.org의 XDG 크로스 데스크탑을 위한 것뿐만 아니라 이러한 사양을 기반으로 한 데스크탑 관리자 구현도 가능합니다. 예를 들어, 시스템 전체에 적용되는 Firefox 아이콘 하나를 들 수 있습니다. 분명히 XDG 작성자는 사용자가 동일한 응용 프로그램의 여러 버전을 설치할 수 있다고 생각조차 하지 않았습니다.

다양한 버전의 Firefox 아이콘

나는 시스템 통합 문제를 피하기 위해 Linux 세계가 Mac OS X로부터 무엇을 배울 수 있는지 궁금했습니다. 시간이 있고 이에 관심이 있다면 최초의 Mac OS X 엔지니어 중 한 명인 Arnaud Gurdol이 말한 내용을 꼭 읽어보세요.

우리는 애플리케이션 아이콘을 어딘가(서버, 외장 드라이브)에서 컴퓨터 드라이브로 드래그하는 것만큼 쉽게 애플리케이션을 설치하고 싶었습니다. 이를 위해 애플리케이션 패키지는 시스템이 애플리케이션을 처리하기 위해 알아야 하는 아이콘, 버전, 처리 중인 파일 유형, URL 구성표 유형을 포함한 모든 정보를 저장합니다. 여기에는 Icon Services 및 Launch Services 데이터베이스의 '중앙 저장소'에 대한 정보도 포함됩니다. 성능을 지원하기 위해 응용 프로그램은 여러 '잘 알려진' 위치(시스템 및 사용자 응용 프로그램 디렉터리 및 사용자가 응용 프로그램이 포함된 디렉터리의 Finder로 이동하는 경우 자동으로 다른 일부)에서 '검색'됩니다. 실제로 이것은 매우 잘 작동했습니다.

https://youtu.be/qQsnqWJ8D2c
Apple WWDC 2000 세션 144 - Mac OS X: 애플리케이션 패키징 및 문서 인쇄.

Linux 데스크톱에는 이 인프라와 같은 것이 없으므로 AppImage 프로젝트의 구조적 제한 사항에 대한 해결 방법을 찾고 있습니다.

하이쿠가 구출하러 오고 있나요?

그리고 한 가지 더: 데스크탑 환경의 기반인 Linux 플랫폼은 너무 과소 지정되는 경향이 있어 일관된 풀 스택 시스템에서 매우 단순한 많은 것들이 Linux에서는 좌절스러울 정도로 단편화되고 복잡합니다. 나는 전체 보고서를 데스크톱 환경용 Linux 플랫폼과 관련된 문제에 전념했습니다(지식이 풍부한 개발자는 모든 것이 오랫동안 이런 상태로 유지될 것이라고 확인했습니다).

2018년 리눅스 데스크탑 환경의 문제점에 대한 나의 보고서

심지어 리누스 토발즈(Linus Torvalds)도 작업 공간 아이디어가 실패한 이유가 단편화 때문이라고 인정했습니다.

하이쿠를 만나서 반가워요!

Haiku는 모든 것을 놀랍도록 단순하게 만듭니다.

AppImage를 Haiku로 "포팅"하는 순진한 접근 방식은 단순히 해당 구성 요소를 빌드(주로 Runtime.c 및 서비스)하는 것이지만(가능한 경우도 있습니다!), 이는 Haiku에 큰 이점을 제공하지 않습니다. 실제로 이러한 문제의 대부분은 하이쿠에서 해결되었으며 개념적으로도 타당하기 때문입니다. Haiku는 오랫동안 Linux 데스크탑 환경에서 찾고 있었지만 거기에 없다고 믿을 수 없었던 시스템 인프라 빌딩 블록을 정확하게 제공합니다. 즉:

믿거나 말거나, 이는 많은 Linux 사용자가 극복할 수 없는 문제입니다. Haiku에서는 모든 것이 자동으로 수행됩니다!

• 실행 비트가 없는 ELF 파일은 파일 관리자에서 두 번 클릭하면 자동으로 생성됩니다.
• 애플리케이션에는 파일 관리자에 표시되는 아이콘과 같은 내장 리소스가 있을 수 있습니다. 아이콘이 있는 특수 디렉토리에 이미지 묶음을 복사할 필요가 없으므로 애플리케이션을 삭제하거나 이동한 후에 이미지를 정리할 필요가 없습니다.
• 애플리케이션을 문서와 연결하기 위한 데이터베이스가 있으므로 이를 위해 파일을 복사할 필요가 없습니다.
• 실행 파일 옆의 lib/ 디렉터리에서는 기본적으로 라이브러리가 검색됩니다.
• 수많은 배포판과 데스크탑 환경이 없으며, 무엇이든지 작동하는 것은 어디에서나 작동합니다.
• 응용 프로그램 디렉터리와 다른 별도의 실행 모듈은 없습니다.
• 애플리케이션에는 리소스에 대한 절대 경로가 내장되어 있지 않으며 런타임 시 위치를 결정하는 특수 기능이 있습니다.
• 압축된 파일 시스템 이미지라는 아이디어가 도입되었습니다. 이것은 모든 hpkg 패키지입니다. 이들 모두는 커널에 의해 마운트됩니다.
• 달리 명시적으로 지정하지 않는 한, 각 파일은 해당 파일을 만든 응용 프로그램에서 열립니다. 정말 멋지네요!

png 파일이 XNUMX개 있습니다. 두 번 클릭하면 다른 응용 프로그램에서 열릴 것임을 나타내는 다양한 아이콘에 유의하세요. 또한 사용자가 개별 애플리케이션을 선택할 수 있는 "다음으로 열기:" 드롭다운 메뉴를 참고하세요. 얼마나 간단합니까!

Linux의 AppImage에 필요한 많은 목발과 해결 방법이 Haiku에서는 불필요한 것처럼 보입니다. Haiku는 우리의 요구 사항 대부분을 처리할 수 있는 단순성과 정교함을 핵심으로 갖고 있습니다.

결국 Haiku에는 앱 패키지가 필요합니까?

이것은 큰 질문으로 이어진다. Linux보다 Haiku에서 AppImage와 같은 시스템을 만드는 것이 훨씬 더 쉽다면 그렇게 할 가치가 있을까요? 아니면 hpkg 패키지 시스템을 갖춘 Haiku가 그러한 아이디어를 개발할 필요성을 효과적으로 제거했습니까? 글쎄, 대답하려면 AppImages의 존재 동기를 살펴봐야 합니다.

사용자의 관점

최종 사용자를 살펴보겠습니다.

• 관리자(루트) 비밀번호를 묻지 않고 애플리케이션을 설치하고 싶습니다. Haiku에는 관리자라는 개념이 없으며, 개인 시스템이므로 사용자가 모든 권한을 갖습니다! (원칙적으로는 멀티플레이어 모드에서 이를 상상할 수 있습니다. 개발자가 간단하게 유지하길 바랍니다.)
• 내 배포판에 나타날 때까지 기다리지 않고 가장 뛰어난 최신 버전의 응용 프로그램을 얻고 싶습니다(적어도 전체 운영 체제를 업데이트하지 않는 한 이는 "절대"를 의미하지 않는 경우가 많습니다). Haiku에서는 플로팅 릴리스를 사용하여 이 문제를 "해결"했습니다. 즉, 가장 뛰어난 최신 버전의 애플리케이션을 얻을 수 있지만 이를 위해서는 시스템의 나머지 부분을 지속적으로 업데이트하여 효과적으로 "움직이는 대상"으로 전환해야 합니다..
• 최신 버전에서 무엇이 손상되었는지 알 수 있는 방법이 없거나 웹 개발자로서 다른 버전의 브라우저에서 내 작업을 테스트해야 하기 때문에 동일한 애플리케이션의 여러 버전을 나란히 놓고 싶습니다. 하이쿠는 첫 번째 문제를 해결하지만 두 번째 문제는 해결하지 않습니다. 업데이트는 롤백되지만 전체 시스템에 대해서만 가능합니다. 예를 들어 여러 버전의 WebPositive 또는 LibreOffice를 동시에 실행하는 것은 (내가 아는 한) 불가능합니다.

개발자 중 한 명이 이렇게 썼습니다.

본질적으로 그 근거는 다음과 같습니다. 사용 사례가 너무 드물기 때문에 최적화하는 것이 의미가 없습니다. HaikuPorts에서는 이를 특별한 경우로 취급하는 것이 허용 가능한 것 이상인 것 같습니다.

• 시작 드라이브가 아닌 내가 좋아하는 곳에 앱을 보관해야 합니다. 디스크 공간이 부족한 경우가 많기 때문에 애플리케이션(다운로드한 모든 버전)을 저장하려면 외부 드라이브나 네트워크 디렉터리를 연결해야 합니다. 이러한 드라이브를 연결하려면 두 번 클릭하여 실행되는 애플리케이션이 필요합니다. Haiku는 이전 버전의 패키지를 저장하지만 해당 패키지를 외부 드라이브로 이동하는 방법이나 나중에 거기에서 응용 프로그램을 시작하는 방법을 모릅니다.

개발자 의견:

기술적으로 이는 mount 명령을 사용하여 이미 가능합니다. 물론, 관심 있는 사용자가 충분히 확보되면 이를 위한 GUI를 만들 것입니다.

• 수동으로 관리할 수 없는 파일 시스템에 분산된 수백만 개의 파일이 필요하지 않습니다. 쉽게 다운로드, 이동, 삭제할 수 있는 애플리케이션당 하나의 파일을 원합니다. Haiku에서는 이 문제가 패키지를 사용하여 해결됩니다. .hpkg, 예를 들어 Python과 같이 수천 개의 파일을 하나로 전송합니다. 하지만 예를 들어 Python을 사용하는 Scribus가 있다면 최소한 두 개의 파일을 처리해야 합니다. 그리고 서로 호환되는 버전을 유지하도록 주의를 기울여야 합니다.

동일한 Linux에서 나란히 실행되는 여러 버전의 AppImage

애플리케이션 개발자의 관점

애플리케이션 개발자의 관점에서 살펴보겠습니다.

• 전체 사용자 경험을 제어하고 싶습니다. 나는 언제 어떻게 애플리케이션을 릴리스해야 하는지를 운영 체제에 의존하고 싶지 않습니다. Haiku를 사용하면 개발자가 자신의 hpkg 저장소로 작업할 수 있지만 이는 사용자가 수동으로 설정해야 하므로 아이디어가 "덜 매력적"이 된다는 것을 의미합니다.
• 내가 배포하는 웹사이트에 다운로드 페이지가 있습니다. .exe 윈도우용, .dmg Mac용 및 .AppImage 리눅스용. 아니면 이 페이지에 대한 액세스로 수익을 창출하고 싶을 수도 있습니다. 무엇이든 가능합니까? 하이쿠에는 무엇을 넣어야 하나요? 파일이면 충분해요 .hpkg HaikuPorts에서만 종속성을 사용합니다.
• 내 소프트웨어에는 특정 버전의 다른 소프트웨어가 필요합니다. 예를 들어, Krita에는 적어도 패치가 Qt로 다시 푸시될 때까지 Qt의 패치 버전, 또는 Krita의 특정 버전에 맞게 조정된 Qt가 필요하다는 것이 알려져 있습니다. 애플리케이션에 맞게 자체 Qt를 패키지로 패키징할 수 있습니다. .hpkg, 그러나 이는 환영받지 못할 가능성이 높습니다.

일반 애플리케이션 다운로드 페이지. 하이쿠에 대해 여기에 무엇을 게시해야 합니까?

번들(AppDir 또는 .app Apple 스타일) 및/또는 이미지(고도로 수정된 AppImages 또는 .dmg Apple에서) 응용프로그램이 Haiku 데스크탑 환경에 유용한 추가 기능입니까? 아니면 전체 그림을 희석시키고 단편화로 이어져 복잡성을 더하게 될까요? 나는 충격을 받았습니다. 한편으로 하이쿠의 아름다움과 정교함은 일반적으로 무언가를 수행하는 방법이 여러 가지가 아니라 한 가지라는 사실에 기반을 두고 있습니다. 반면, 카탈로그 및/또는 애플리케이션 제품군을 위한 대부분의 인프라는 이미 마련되어 있으므로 시스템은 나머지 몇 퍼센트도 제대로 갖춰지도록 요구합니다.

개발자에 따르면 씨. 뒤뚱뒤뚱

Linux에서는 (카탈로그 및 애플리케이션 키트 - 약. 역자)은 시스템 문제에 대한 기술적인 해결책일 가능성이 높습니다. Haiku에서는 단순히 시스템 문제를 해결하는 것을 선호합니다.

너는 어떻게 생각하니?

대답하기 전에...

잠깐, 현실을 빠르게 확인해 보겠습니다. 사실 응용 프로그램 디렉토리 - 이미 하이쿠의 일부:

응용 프로그램 디렉터리는 이미 Haiku에 있지만 파일 관리자에서는 아직 지원되지 않습니다.

예를 들어 Macintosh Finder만큼 지원이 잘 되지는 않습니다. QtCreator 디렉토리의 왼쪽 상단에 "QtCreator" 이름과 아이콘이 있고 두 번 클릭하면 응용 프로그램이 실행된다면 얼마나 좋을까요?

조금 더 일찍 나는 이미 물었다:

모든 앱 스토어와 배포 저장소가 앱과 앱의 종속성을 잊어버린 지금 XNUMX년이 된 앱을 실행할 수 있습니까? 귀하는 미래에도 현재 직장에 계속 접근할 수 있다고 확신하십니까?

이미 Haiku의 답변이 있습니까? 아니면 카탈로그와 애플리케이션 번들이 도움이 될까요? 나는 그들이 할 수 있다고 생각합니다.

씨에 따르면 뒤뚱뒤뚱:

예, 우리는 질문에 대한 답을 가지고 있습니다. 우리는 누군가가 파일 형식을 올바른 방식으로 읽거나 일대일 기능을 제공할 수 있을 때까지 필요한 만큼 이러한 애플리케이션을 지원할 것입니다. Haiku에서 BeOS R5 앱을 지원하겠다는 우리의 약속은 이를 증명합니다...

그것은 확실합니다!

하이쿠는 어떤 조치를 취해야 할까요?

나는 hpkg, 디렉토리 및 애플리케이션 이미지의 평화로운 공존을 상상할 수 있습니다.

• 시스템 소프트웨어는 .hpkg
• 가장 자주 사용되는 소프트웨어(특히 롤링 릴리스를 예약해야 하는 소프트웨어)의 경우 다음을 사용하세요. .hpkg (전체 사례의 약 80%)
• 일부는 다음을 통해 설치됨 .hpkg, 애플리케이션은 애플리케이션 디렉토리 인프라(예: QtCreator)로 이동하면 이점을 얻을 수 있습니다. .hpkg, 이전과.

씨. waddlesplash는 다음과 같이 씁니다:

필요한 것은 응용 프로그램을 보는 것뿐입니다. /system/apps대신 데스크바의 디렉토리를 사용자가 더 쉽게 관리할 수 있도록 만들어야 합니다. /system/apps MacOS와 달리 사용자가 정기적으로 열어서 볼 수는 없습니다. 그러한 상황에 대해 하이쿠는 다른 패러다임을 가지고 있지만 이론적으로는 이 옵션이 허용됩니다.

• Haiku는 애플리케이션 이미지 실행, 야간 연속 및 소프트웨어 테스트 빌드뿐만 아니라 사용자가 개인 및 내부 소프트웨어 및 기타 특수 사용 사례를 위해 "제때에 동결"하려는 경우를 위한 인프라를 받습니다(약 20% 모든). 이 이미지에는 애플리케이션을 실행하는 데 필요한 파일이 포함되어 있습니다. .hpkg, 시스템에 의해 마운트되고 애플리케이션이 완료된 후 - 마운트 해제됩니다. (아마도 파일 관리자가 파일을 넣을 수 .hpkg 자동으로 또는 사용자의 요청에 따라 애플리케이션 이미지에 애플리케이션을 네트워크 디렉터리나 외부 드라이브로 드래그하는 경우와 같습니다. 그것은 단지 노래입니다! 아니면 오히려 시-하이쿠.) 반면에 사용자는 이미지의 내용을 파일 형태로 설치하고 싶을 수도 있습니다..hpkg, 그 후에는 HaikuDepot을 통해 설치된 것과 동일한 방식으로 업데이트되고 처리됩니다... 브레인스토밍이 필요합니다.

Mr.의 견적 뒤뚱뒤뚱:

외부 드라이브나 네트워크 디렉터리에서 애플리케이션을 실행하는 것이 잠재적으로 유용할 수 있습니다. 그리고 pkgman에 더 많은 "영역"을 구성하는 기능을 추가하는 것은 확실히 좋은 기능이 될 것입니다.

이러한 시스템은 hpkg, 디렉토리 및 응용 프로그램 이미지를 활용합니다. 그들은 개별적으로 훌륭하지만 함께하면 무적이 될 것입니다.

결론

Haiku는 PC에 간단하고 정교한 사용자 경험을 제공하는 프레임워크를 갖추고 있으며 일반적으로 Linux PC에 제공되는 것보다 훨씬 뛰어납니다. 패키지 시스템 .hpkg 가 그러한 예 중 하나이지만 시스템의 나머지 부분에도 정교함이 묻어 있습니다. 그러나 Haiku는 적절한 디렉토리 및 애플리케이션 이미지 지원을 통해 이점을 얻을 수 있습니다. 이를 가장 잘 수행하는 방법은 나보다 하이쿠의 철학과 건축을 훨씬 더 잘 아는 사람들과 논의할 가치가 있습니다. 결국, 나는 일주일 조금 넘게 하이쿠를 사용해 왔습니다. 그럼에도 불구하고 나는 하이쿠의 디자이너, 개발자, 건축가가 이 새로운 관점으로부터 이익을 얻을 것이라고 믿습니다. 적어도 나는 그들의 '대련 파트너'가 되어주어서 기쁘다. 저는 Linux 애플리케이션 카탈로그 및 번들에 대한 실무 경험이 10년 이상이며 Haiku에서 이러한 용도를 찾고 싶습니다. 제 생각에는 이것이 완벽하게 적합하다고 생각합니다. 내가 제안한 잠재적인 해결책은 결코 내가 설명한 문제에 대한 유일한 올바른 해결책이 아니며, 하이쿠 팀이 더 우아한 다른 해결책을 찾기로 결정한다면 나는 전적으로 그것을 지지할 것입니다. 기본적으로 시스템을 어떻게 만들까에 대한 아이디어는 이미 생각하고 있어요. hpkg 작동 방식을 바꾸지 않고도 더욱 놀랍습니다. Haiku 팀은 패키지 관리 시스템을 구현할 때 오랫동안 애플리케이션 번들에 대해 생각해 왔지만 불행하게도 그 아이디어는 "구식"이 되었습니다. 이제 그것을 되살릴 시간이 되었을까요?

직접 시도해 보세요! 결국 Haiku 프로젝트는 DVD 또는 USB에서 부팅하기 위한 이미지를 제공합니다. 매일.
질문있으세요? 러시아어로 여러분을 초대합니다 전보 채널.

오류 개요: C 및 C++로 발에 총을 쏘는 방법. Haiku OS 레시피 모음

부터 저자 번역: 이것은 하이쿠에 관한 시리즈의 여덟 번째이자 마지막 기사입니다.

기사 목록: 처음으로 초 세 번째 넷째 다섯째 여섯 번째 일곱 번째

등록된 사용자만 설문 조사에 참여할 수 있습니다. 로그인제발

hpkg 시스템을 Linux로 포팅하는 것이 합리적입니까?

• Да

• 아니

• 이미 구현되어 있으니 댓글로 쓰겠습니다

20명의 사용자가 투표했습니다. 5명의 사용자가 기권했습니다.

출처 : habr.com