하이쿠와 함께한 여섯 번째 날: 리소스, 아이콘, 패키지 살펴보기

TL; DR: Haiku는 PC용으로 특별히 설계된 운영 체제이므로 데스크톱 환경을 다른 운영 체제보다 훨씬 더 좋게 만드는 몇 가지 요령이 있습니다. 하지만 어떻게 작동하나요?

최근에 의외의 좋은 시스템인 하이쿠를 발견했습니다. 특히 Linux 데스크톱 환경에 비해 얼마나 원활하게 실행되는지는 여전히 놀랍습니다. 오늘은 후드 아래를 살펴보겠습니다. 심층적인 이해를 위해 필요한 경우 원래 Macintosh, Mac OS X 및 Linux 데스크톱 환경(freedesktop.org의 XDG 표준)과 비교해 보겠습니다.

ELF 파일의 리소스

어제 나는 IconOMatic이 ELF 실행 파일의 rdef 리소스에 아이콘을 저장할 수 있다는 것을 배웠습니다. 오늘은 실제로 어떻게 작동하는지 보고 싶습니다.

자원? 인용 부호 부터 브루스 혼, Macintosh Finder의 원저자이자 Macintosh Resource Manager의 "아버지":

저는 전통적인 코딩의 엄격한 성격이 걱정됩니다. 나에게는 동적으로 아무것도 변경할 수 없는 코드에 고정된 애플리케이션이라는 아이디어 자체가 가장 야만적입니다. 런타임 시 최대한 많은 변경이 가능해야 합니다. 물론 애플리케이션 코드 자체는 변경할 수 없지만 코드를 다시 컴파일하지 않고도 뭔가가 변경될 수는 있겠죠?

원래 Macintosh에서는 이러한 파일에 "데이터 섹션"과 "리소스 섹션"이 있으므로 아이콘, 번역 등과 같은 항목을 매우 쉽게 저장할 수 있습니다. 실행 파일에서.

Mac에서는 이것이 사용됩니다 해상도편집, 갑자기 리소스를 편집하기 위한 그래픽 프로그램입니다.

원래 Macintosh의 ResEdit

그 결과 아이콘, 메뉴 항목, 번역 등의 편집이 가능해졌습니다. 충분히 쉽지만 여전히 애플리케이션과 함께 "이동"합니다.
어쨌든 이 접근 방식에는 큰 단점이 있었습니다. 이는 Apple 파일 시스템에서만 작동했으며, 이는 Apple이 Mac OS X로 전환할 때 "리소스 섹션"을 포기한 이유 중 하나였습니다.
Mac OS X에서 Apple은 파일 시스템 독립적인 솔루션을 원했기 때문에 파일 관리자가 디렉터리가 아닌 파일처럼 "불투명 개체"로 처리하는 디렉터리인 패키지(NeXT의) 개념을 채택했습니다. 다음 형식의 애플리케이션이 포함된 모든 패키지 .app 무엇보다도 파일이 있습니다 Info.plist (Apple의 JSON 또는 YAML과 같은 형식) 애플리케이션 메타데이터가 포함되어 있습니다.

Mac OS X 응용 프로그램 패키지의 Info.plist 파일에 대한 키입니다.

아이콘, UI 파일 등의 리소스는 패키지에 파일로 저장됩니다. 이 개념은 실제로 NeXT의 뿌리로 거슬러 올라갑니다.

1.0년 NeXTSTEP 1989의 Mathematica.app: 터미널에서는 파일 디렉터리로 표시되지만 그래픽 파일 관리자에서는 단일 개체로 표시됩니다.

Haiku의 기반이 되는 개념인 BeOS로 돌아가 보겠습니다. 개발자는 PEF(PowerPC)에서 ELF(x86)(Linux에서 사용되는 것과 동일)로 전환할 때 ELF 파일 끝에 리소스 섹션을 추가하기로 결정했습니다. 자체적으로 적절한 ELF 섹션을 사용하지 않았으며 단순히 ELF 파일 끝에 추가되었습니다. 프로그램의 결과로 strip 그리고 binutils의 다른 사람들은 이 사실을 모르고 그냥 잘라버렸습니다. 따라서 BeOS에서 ELF 파일에 리소스를 추가할 때 Linux 도구로 조작하지 않는 것이 좋습니다.

지금 하이쿠에게 무슨 일이 일어나고 있는 걸까요? 기본적으로는 거의 동일합니다.

이론적으로는 ELF의 원하는 섹션에 리소스를 배치하는 것이 가능합니다. irc.freenode.net의 #haiku 채널 개발자에 따르면:

ELF를 사용하면 섹션이 더 이해가 될 것입니다... 우리가 그런 식으로 하지 않는 유일한 이유는 그것이 우리가 BeOS에서 했던 일이기 때문입니다."
그리고 지금 이것을 바꾸는 것은 의미가 없습니다.

자원 관리

리소스는 구조화된 "리소스" 형식으로 작성됩니다. 기본적으로 크기와 콘텐츠가 포함된 리소스 목록입니다. 나는 기억했다 ar 형식.
Haiku의 리소스를 확인하는 방법은 무엇입니까? ResEdit 같은 것이 있나요?
에 따르면 선적 서류 비치:

애플리케이션 패키지에 제공된 리소스를 보려면 실행 파일을 다음과 같은 프로그램으로 드래그하면 됩니다. 리소스러. 터미널로 가서 명령을 실행할 수도 있습니다 listres имя_файла.

Resourcer는 HaikuDepot에서 사용할 수 있지만 충돌이 발생합니다.

ELF 파일의 리소스를 관리하는 방법은 무엇입니까? 사용 rsrc и rdef. rdef 파일은 다음 위치에 수집됩니다. rsrc. 파일 rdef 일반 텍스트 형식으로 저장되므로 작업하기가 훨씬 쉽습니다. 파일 형식 rsrc ELF 파일 끝에 추가됩니다. 플레이해 봅시다:

~> rc -h
Haiku Resource Compiler 1.1To compile an rdef script into a resource file:
    rc [options] [-o <file>] <file>...To convert a resource file back into an rdef script:
    rc [options] [-o <file>] -d <file>...Options:
    -d --decompile       create an rdef script from a resource file
       --auto-names      construct resource names from ID symbols
    -h --help            show this message
    -I --include <dir>   add <dir> to the list of include paths
    -m --merge           do not erase existing contents of output file
    -o --output          specify output file name, default is out.xxx
    -q --quiet           do not display any error messages
    -V --version         show software version and license

프로그램을 사용하시면 됩니다 xres 점검 및 제어를 위해:

/> xres
Usage: xres ( -h | --help )
       xres -l <file> ...
       xres <command> ...The first form prints this help text and exits.The second form lists the resources of all given files.The third form manipulates the resources of one or more files according to
the given commands.
(...)

좋아, 한번 해보자?

/> xres -l /Haiku/system/apps/WebPositive/Haiku/system/apps/WebPositive resources:type           ID        size  name
------ ----------- -----------  --------------------
'MIMS'           1          36  BEOS:APP_SIG
'APPF'           1           4  BEOS:APP_FLAGS
'MSGG'           1         421  BEOS:FILE_TYPES
'VICN'         101        7025  BEOS:ICON
'VICN'         201          91  kActionBack
'VICN'         202          91  kActionForward
'VICN'         203         300  kActionForward2
'VICN'         204         101  kActionStop
'VICN'         206         243  kActionGoStart
'MSGG'         205        1342  kActionGo
'APPV'           1         680  BEOS:APP_VERSION

리소스 및 형식에 대해 자세히 알아보기 rdef 당신은 읽을 수있다 여기에.

표준 리소스 유형

리소스에 무엇이든 넣을 수 있지만 몇 가지 정의된 표준 유형이 있습니다.

• app_signature: MIME 애플리케이션 유형, 파일 열기 매핑, 실행, IPC 등을 위한 것입니다.
• app_name_catalog_entry: 애플리케이션 이름은 대개 영어로 되어 있기 때문에, 번역된 이름이 있는 곳을 지정하여 다른 언어 사용자가 원할 경우 번역된 애플리케이션 이름을 볼 수 있도록 할 수 있습니다.
• app_version: 정확히 당신이 생각한 것
• app_flags: 나타내다 registrar 신청서 처리 방법. 나는 눈에 보이는 것보다 더 많은 것이 있다고 생각합니다. 예를 들어, B_SINGLE_LAUNCH, 이는 사용자가 요청할 때마다 시스템이 새로운 애플리케이션 프로세스를 시작하도록 강제합니다(Linux의 대부분의 애플리케이션에 동일한 원칙이 사용됩니다). 먹다 B_MULTIPLE_LAUNCH, 프로세스가 다음 동안 실행되도록 합니다. 각 파일. 마지막으로 B_EXCLUSIVE_LAUNCH, 사용자가 실행하는 빈도에 관계없이 시스템이 한 번에 하나의 프로세스만 실행하도록 강제합니다(예를 들어, 이것이 Linux에서 Firefox가 실행되는 방식입니다. 다음 기능을 사용하여 Qt 애플리케이션에서도 동일한 결과를 얻을 수 있습니다) QtSingleApplication). 애플리케이션 B_EXCLUSIVE_LAUNCH 사용자가 다시 실행하려고 하면 알림을 받습니다. 예를 들어 사용자가 도움을 받아 열려고 하는 파일의 경로를 받습니다.
• vector_icon: 벡터 응용 프로그램 아이콘(BeOS에는 벡터 아이콘이 없으며 대부분의 응용 프로그램에는 실행 파일에 두 개의 래스터 아이콘이 있습니다).

물론 원하는 ID와 유형으로 리소스를 추가한 다음 애플리케이션 자체 또는 클래스를 사용하는 다른 애플리케이션에서 읽을 수 있습니다. BResources. 하지만 먼저 아이콘이라는 매혹적인 주제를 살펴 보겠습니다.

하이쿠 스타일의 벡터 아이콘

물론 Haiku가 최고의 아이콘 형식을 선택했을 뿐만 아니라 이 부분에서 Linux 데스크탑 환경의 상황은 이상적이지 않습니다.

me@host:~$ ls /usr/share/icons/hicolor/
128x128  256x256  512x512           index.theme
160x160  28x28    64x64             scalable
16x16    32x32    72x72             symbolic
192x192  36x36    8x8
22x22    42x42    96x96
24x24    48x48    icon-theme.cache

이것만 봐도 이미 이 작품이 어떤 작품인지 감이 오실 겁니다.

물론, 이해하실 수 있듯이 벡터 아이콘을 포함하는 확장 가능한 아이콘도 있습니다. 그렇다면 왜 다른 것이 있습니까? 작은 크기로 벡터 그래픽을 그린 결과는 이상적이지 않을 수 있기 때문입니다. 다양한 크기에 최적화된 다양한 옵션을 갖고 싶습니다. Linux 데스크탑 환경에서는 파일 시스템 전체에 다양한 크기의 아이콘을 분산시켜 이를 달성합니다.

me@host:~$ find /usr/share/icons/ -name 'firefox.*'
/usr/share/icons/HighContrast/16x16/apps/firefox.png
/usr/share/icons/HighContrast/22x22/apps/firefox.png
/usr/share/icons/HighContrast/24x24/apps/firefox.png
/usr/share/icons/HighContrast/256x256/apps/firefox.png
/usr/share/icons/HighContrast/32x32/apps/firefox.png
/usr/share/icons/HighContrast/48x48/apps/firefox.png
/usr/share/icons/elementary-xfce/apps/128/firefox.png
/usr/share/icons/elementary-xfce/apps/16/firefox.png
/usr/share/icons/elementary-xfce/apps/22/firefox.png
/usr/share/icons/elementary-xfce/apps/24/firefox.png
/usr/share/icons/elementary-xfce/apps/32/firefox.png
/usr/share/icons/elementary-xfce/apps/48/firefox.png
/usr/share/icons/elementary-xfce/apps/64/firefox.png
/usr/share/icons/elementary-xfce/apps/96/firefox.png
/usr/share/icons/hicolor/128x128/apps/firefox.png

참고: Firefox에는 서로 다른 버전이 있다는 개념이 없습니다. 따라서 시스템에 여러 버전의 애플리케이션이 있는 상황을 적절하게 처리하는 것은 불가능합니다.

다양한 버전의 다양한 Firefox 아이콘. 현재 다양한 목발 없이는 Linux에서 이를 처리하는 것이 불가능합니다.

Mac OS X에서는 이를 좀 더 미묘하게 처리합니다.

Mac:~ me$ find /Applications/Firefox.app | grep icns
/Applications/Firefox.app/Contents/MacOS/crashreporter.app
/Contents/Resources/crashreporter.icns
/Applications/Firefox.app/Contents/MacOS/updater.app/Contents/Resources/updater.icns
/Applications/Firefox.app/Contents/Resources/document.icns
/Applications/Firefox.app/Contents/Resources/firefox.icns

파일이 하나 있는 것을 볼 수 있습니다. firefox.icns 패키지에 Firefox.app, 동일한 애플리케이션의 다양한 버전이 서로 다른 아이콘을 갖도록 모든 크기를 포함합니다.
훨씬 낫다! 아이콘은 애플리케이션과 함께 이동하며 모든 리소스는 하나의 파일에 있습니다.

하이쿠로 돌아가자. 놀라운 솔루션이며 예외는 없습니다. 에 따르면 선적 서류 비치:

작은 크기와 빠른 렌더링에 고도로 최적화된 특수 HVIF 형식이 개발되었습니다. 따라서 대부분의 아이콘은 래스터나 널리 사용되는 SVG 형식보다 훨씬 작습니다.

그리고 여전히 최적화되어 있습니다.

다른 형식과 비교한 HVIF의 아이콘 크기.

그 차이는 크기의 순서입니다!

하지만 마법은 여기서 끝나지 않습니다. 동일한 HVIF라도 벡터 형식이더라도 표시되는 크기에 따라 서로 다른 세부 수준을 표시할 수 있습니다.

렌더 크기에 따라 다양한 세부 수준(LOD)

이제 단점에 대해 말하자면: SVG를 ImageMagick에 넣어서 하루라고 할 수 없으며, HVIF 형식의 아이콘을 생성하려면 여러 주기를 거쳐야 합니다. 여기에 설명. 그러나 IconOMatic은 SVG를 매우 불완전하게 가져올 수 있습니다. SVG 세부 정보의 약 90%는 어느 정도 가져오며 나머지 10%는 수동으로 구성하고 변경해야 합니다. HVIF가 어떻게 마법을 발휘하는지 자세히 알아보세요. 하나는 수 블로그에서 레아 갠슨

애플리케이션에 아이콘 추가

이제 생성된 패키지에 아이콘을 추가할 수 있습니다. 지난 번에, 수신된 모든 정보를 고려합니다.
글쎄, 나는 지금 당장 "Hello, World" QtQuickApp에 대한 내 자신의 아이콘을 그리고 싶지 않기 때문에 Qt Creator에서 아이콘을 꺼냅니다.

/Haiku/home> xres /Haiku/system/apps/QtCreator/bin/Qt Creator  -o /Haiku/home/QtQuickApp/QtQuickApp  -a VICN:101:BEOS:ICON /Haiku/system/apps/QtCreator/bin/Qt Creator

아이콘이 복사되었는지 확인해 보겠습니다.

/Haiku/home> xres -l /Haiku/home/QtQuickApp/QtQuickApp/Haiku/home/QtQuickApp/QtQuickApp
resources:type           ID        size  name
------ ----------- -----------  --------------------
'VICN'         101      152238  BEOS:ICON

좋아보이는데 새 아이콘을 복사하면 왜 나타나지 않는 걸까요?

복사된 VICN:101:BEOS:ICONs는 아직 파일 관리자에서 응용 프로그램 아이콘으로 사용되지 않습니다.

내가 놓친 게 무엇입니까?

개발자 의견:

파일을 생성해야 합니다 rdef 모든 리소스를 사용하여 명령을 실행합니다. rc имя.rdef, 그러면 파일이 생성됩니다. .rsrc. 그런 다음 명령을 실행해야합니다 resattr -o имя_бинарника имя.rsrc. 최소한 나는 스크립트에 아이콘을 추가하기 위해 이와 같은 명령을 사용합니다.

글쎄요, 저는 속성이 아닌 리소스를 만들고 싶었습니다. 정말 혼란스러워요.

파일 시스템을 사용한 스마트 캐싱

ELF 속성을 열고 읽는 속도가 느립니다. 위에서 쓴 것처럼 아이콘은 파일 자체에 리소스로 기록됩니다. 이 방법은 더 안정적이며 다른 파일 시스템으로 복사해도 살아남을 수 있습니다. 그러나 이는 파일 시스템 속성에도 복사됩니다. 예를 들면 다음과 같습니다. BEOS:ICON. 이는 BFS와 같은 특정 파일 시스템에서만 작동합니다. 이 솔루션은 빠르게 작동하므로 시스템(트래커 및 데스크바)에 표시되는 아이콘은 이 확장 속성에서 읽혀집니다. 속도가 중요하지 않은 일부 위치(예: 일반적인 "정보" 창)에서는 시스템이 파일의 리소스에서 직접 아이콘을 받습니다. 그러나 이것이 끝이 아닙니다. Mac에서는 사용자가 애플리케이션, 디렉토리, 문서의 아이콘을 자신의 아이콘으로 바꿀 수 있다는 점을 기억하세요. Mac에서는 예를 들어 이러한 "중요한" 작업을 수행하는 것이 가능하기 때문입니다. 새 Slack 아이콘을 이전 아이콘으로 교체. Haiku에서는 리소스(파일에 있음)를 애플리케이션과 함께 제공되는 원본 아이콘으로 생각해야 하며, 속성(BFS 파일 시스템에 있음)을 사용자가 마음대로 변경할 수 있도록 하는 것으로 생각해야 합니다(단, 힌트는 아이콘 위에 사용자 정의 아이콘을 삽입하기 위한 GUI는 선택 사항입니다.) 아직 기본적으로 구현되지 않았습니다.

파일 시스템 속성 확인

과 resaddr 파일 시스템 속성을 확인하고 설정할 수 있습니다.

/> resattr
Usage: resattr [ <options> ] -o <outFile> [ <inFile> ... ]

Reads resources from zero or more input files and adds them as attributes
to the specified output file, or (in reverse mode) reads attributes from
zero or more input files and adds them as resources to the specified output
file. If not existent the output file is created as an empty file.
(...)

이는 본질적으로 (신뢰할 수 있는) 리소스와 (빠른) 파일 시스템 속성 사이를 오가며 변환을 수행하는 "접착제"입니다. 그리고 시스템은 리소스를 받을 것으로 예상하고 자동으로 복사를 수행하므로 더 이상 걱정하지 않겠습니다.

hpkg 패키지의 마법

현재 (가장 자주) 패키지는 Haiku에서 프로그램을 얻는 데 사용됩니다. .hpkg. 단순한 이름에 속지 마십시오. .hpkg 형식은 비슷한 이름을 가진 다른 형식과 완전히 다르게 작동하며 정말 강력한 기능을 가지고 있습니다.

전통적인 패키지 형식에서는 한 가지(패키지)를 다운로드하면 다른 것(패키지 내부 파일)이 시스템에 설치된다는 사실 때문에 오랫동안 당황했습니다. 기존 방식으로 패키지를 설치할 때 파일을 관리(예: 삭제)하는 것은 매우 어렵습니다. 그리고 패키지의 내용물 때문에 파일 시스템 전체에 분산되어 있음, 일반 사용자가 쓰기 액세스 권한을 가질 수 없는 장소를 포함합니다. 이것은 전체 종류의 프로그램을 생성합니다. 패키지 관리자. 그러나 이미 설치된 소프트웨어를 다른 컴퓨터, 이동식 디스크 또는 파일 서버로 전송하는 것은 완전히 불가능하지는 않더라도 훨씬 더 어려워집니다. 일반적인 Linux 기반 시스템에는 수십만에서 수백만 개의 개별 파일이 있을 수 있습니다. 말할 필요도 없이 이는 시스템을 처음 설치할 때, 일반 패키지를 설치, 업데이트 및 제거할 때, 부팅 볼륨(루트 파티션)을 다른 매체에 복사할 때 취약하고 느립니다.

저는 최종 사용자 애플리케이션을 위한 부분적인 버팀목인 AppImage 프로젝트를 진행하고 있습니다. 이는 애플리케이션이 시작될 때 탑재되는 단일 파일 시스템 이미지에 애플리케이션과 모든 종속성을 수집하는 소프트웨어 배포 형식입니다. 동일한 ImageMagick이 갑자기 단일 파일로 바뀌고 단순한 필사자가 파일 관리자에서 관리하므로 작업이 크게 단순화됩니다. 제안된 방법은 프로젝트 이름에 반영된 것처럼 소프트웨어에만 작동하며 Linux용 소프트웨어 제공에 관련된 사람들이 항상 나에게 화살표를 겨누기 때문에 자체적인 문제도 있습니다.

하이쿠로 돌아가자. 기존 패키지 시스템과 이미지 기반 소프트웨어 제공 간의 최적의 균형을 찾는 것이 가능했습니까? 그녀의 패키지 .hpkg 실제로 압축된 파일 시스템 이미지입니다. 시스템이 부팅되면 커널은 대략 다음과 같은 커널 메시지와 함께 모든 설치 및 활성 패키지를 마운트합니다.

KERN: package_daemon [16042853:   924] active package: "gawk-4.2.1-1-x86_64.hpkg"
KERN: package_daemon [16043023:   924] active package: "ca_root_certificates_java-2019_01_23-1-any.hpkg"
KERN: package_daemon [16043232:   924] active package: "python-2.7.16-3-x86_64.hpkg"
KERN: package_daemon [16043405:   924] active package: "openjdk12_default-12.0.1.12-1-x86_64.hpkg"
KERN: package_daemon [16043611:   924] active package: "llvm_libs-5.0.0-3-x86_64.hpkg"

멋지죠? 조금만 참아보세요. 훨씬 더 시원해질 거예요!

매우 특별한 패키지가 있습니다:

KERN: package_daemon [16040020:   924] active package: "haiku-r1~beta1_hrev53242-1-x86_64.hpkg"

여기에는 커널을 포함하여 매우 최소한의 운영 체제가 포함되어 있습니다. 믿거나 말거나, 커널 자체도 부팅 볼륨(루트 파티션)에서 제거되지 않고 패키지에서 해당 위치로 조심스럽게 로드됩니다. .hpkg. 우와! 나는 이미 Haiku의 전체적인 정교함과 일관성의 일부가 커널과 핵심 사용자 공간부터 패키지 관리와 런타임 인프라에 이르기까지 전체 시스템이 하나의 팀에 의해 공동으로 개발된다는 사실에서 비롯된다고 언급했습니다. Linux에서 이와 같은 작업을 실행하려면 얼마나 많은 그룹과 팀이 필요할지 상상해 보십시오. [나는 PuppyLinux 프로젝트를 상상한다 - 대략. 역자]. 그런 다음 이 접근 방식이 배포판에 채택되는 데 시간이 얼마나 걸릴지 상상해 보세요. 그들은 간단한 문제를 가지고 그것을 여러 수행자에게 나누면 너무 복잡해져서 더 이상 해결할 수 없게 될 것이라고 말합니다. 이 경우 하이쿠가 눈을 떴습니다. 나는 이것이 정확히 지금 Linux에서 일어나고 있는 일이라고 생각합니다(이 경우 Linux는 Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu 스택을 총칭하는 용어입니다).

hpkg를 사용한 시스템 롤백

다음과 같은 상황이 얼마나 자주 발생합니까? 업데이트가 성공했지만 뭔가 제대로 작동하지 않는 것으로 밝혀졌습니까? 기존 패키지 관리자를 사용하는 경우 새 패키지가 설치되기 전의 시점(예: 문제가 발생한 경우)으로 시스템 상태를 되돌리기가 어렵습니다. 일부 시스템은 파일 시스템 스냅샷 형태로 해결 방법을 제공하지만 매우 번거롭고 모든 시스템에서 사용되지는 않습니다. Haiku는 패키지를 사용하여 이 문제를 해결합니다. .hpkg. 시스템에서 패키지가 변경될 때마다 이전 패키지는 삭제되지 않고 다음과 같은 하위 디렉터리에 시스템에 저장됩니다. /Haiku/system/packages/administrative/state-<...>/ 끊임없이. 완료되지 않은 작업은 해당 데이터를 하위 디렉터리에 저장합니다. /Haiku/system/packages/administrative/transaction-<...>/.

함유량 /Haiku/system/packages/administrative. "state..." 디렉터리에는 활성 패키지 이름이 포함된 텍스트 파일이 포함되어 있고 "transaction..." 디렉터리에는 패키지 자체가 포함되어 있습니다.

"이전 활성 상태", 즉 목록 .hpkg 변경 전 활성 패키지는 파일 관리자의 각 작업 후 텍스트 파일에 기록됩니다. /Haiku/system/packages/administrative/state-<...>/activated-packages. 비슷한 방식으로 새로운 "활성 상태"가 텍스트 파일에 기록됩니다. /Haiku/system/packages/administrative/activated-packages.

디렉토리 /Haiku/system/packages/administrative/state-<...>/ 이 상태의 활성 패키지 목록이 포함된 텍스트 파일만 포함하며(패키지를 제거하지 않고 설치한 경우), 패키지가 제거되거나 업데이트된 경우 상태 디렉터리에는 이전 버전의 패키지가 포함됩니다.

시스템이 부팅되면 패키지 목록에 따라 패키지를 활성화(마운트)할지 결정됩니다. 그것은 간단합니다! 다운로드 중에 문제가 발생하면 다운로드 관리자에게 다른 이전 목록을 사용하도록 지시할 수 있습니다. 문제 해결됨!

하이쿠 다운로더. 각 진입점은 해당 "활성 상태"를 표시합니다.

나는 이해하기 쉬운 이름을 가진 간단한 텍스트 파일을 "활성 상태" 목록으로 갖는 접근 방식을 좋아합니다. .hpkg. 이는 사람이 아닌 기계를 위해 만들어진 것과는 극명한 대조를 이룹니다. 무리 파일 시스템의 OSTree 또는 Flatpak에서(Microsoft GUID와 동일한 수준)

각 시점의 활성 패키지 목록

구성 데이터

분명히 카탈로그에는 /Haiku/system/packages/administrative/writable-files 패키지에 대한 구성 파일이 포함되어 있지만 쓰기가 가능합니다. 결국, 당신이 기억하는 것처럼, .hpkg 읽기 전용으로 마운트되었습니다. 따라서 이러한 파일은 쓰기 전에 패키지에서 복사해야 합니다. 의미가 있습니다.

.hpkg 시스템용 GUI 통합

이제 이 반짝이는 가방이 어떻게 생겼는지 살펴보겠습니다. .hpkg 사용자의 업무환경(UX)과의 통합에 대처합니다. 결국 하이쿠는 개인적인 사용을 위한 것입니다. 개인적으로 사용자 경험을 패키지와 비교할 때 기준을 높게 설정했습니다. .app Macintosh에서도 동일한 경험을 갖고 있습니다. .hpkg. Linux의 작업 환경과 상황을 비교하지도 않겠습니다. 다른 환경에 비해 절대적으로 끔찍하기 때문입니다.

다음과 같은 시나리오가 떠오릅니다.

• 패키지 내용을 보고 싶습니다. .hpkg
• 패키지를 설치하고 싶습니다.
• 패키지를 제거하고 싶어요
• 패키지의 일부로 시스템에 제공된 항목을 제거하고 싶습니다.
• 패키지의 일부로 시스템에 제공된 항목을 복사하고 싶습니다.
• 모든 Haiku 설치의 일부가 아닐 수 있는 패키지의 모든 종속성을 다운로드하고 싶습니다(예를 들어 인터넷에 액세스할 수 없는 물리적으로 격리된 컴퓨터가 있습니다.)
• 내 패키지(또는 그 일부)를 부팅 볼륨(루트 파티션)과 별도로 다른 위치로 별도로 이동하고 싶습니다(예를 들어 공간이 부족하기 때문).

이것은 나의 일상 업무에서 발생하는 대부분의 주요 사건을 다루어야 합니다. 자, 시작해 보겠습니다.

패키지 내용물 확인

맥에서 패키지를 마우스 오른쪽 버튼으로 클릭하여 열고 Finder에서 내용을 확인하면 됩니다. 결국, 실제로는 위장된 디렉토리일 뿐입니다! (패키지가 있다는 걸 알아요 .pkg 응용 프로그램은 아니지만 일반 사용자는 대부분 상호 작용하지 않는 시스템 부분의 경우).

하이쿠에 대하여 패키지를 마우스 오른쪽 버튼으로 클릭한 다음 "Contents(목차)"를 클릭하여 안에 무엇이 들어 있는지 확인합니다. 그러나 여기에는 두 번 클릭하여 열 수 없는 파일 목록만 있습니다.
패키지를 (일시적으로) 마운트할 수 있는 방법이 있으면 훨씬 좋을 것 같습니다. .hpkg 파일 관리자를 통해 볼 수 있으며 사용자는 구현 세부 사항에 대해 걱정할 필요가 없습니다. (그런데, 당신은 열 수 있습니다 .hpkg 패키지 Expander, 다른 아카이브처럼 압축을 풀 수 있습니다).

HaikuDepot의 인터페이스를 사용하면 패키지 파일 목록을 볼 수 있지만 예를 들어 README.md를 두 번 클릭하여 내용을 볼 수 있는 방법은 없습니다.

이 범주에서는 Mac이 승리하지만 원하는 HaikuDepot 기능을 추가하는 것은 그리 어렵지 않습니다.

GUI를 통해 패키지 설치

맥에서, 대부분의 디스크 이미지 .dmg 패키지를 포함 .app. 디스크 이미지를 두 번 클릭한 다음 패키지를 드래그하여 복사합니다. /Applications 파인더에서. 이것은 나에게 당연한 일이지만 일부 초보자는 이것을 처리하지 못할 수도 있다고 들었습니다. 기본적으로 Apple은 시스템 전체 디렉토리를 "제안"합니다. /Applications (NeXT에서는 개인뿐만 아니라 네트워크로도 연결되었습니다.) 그러나 응용 프로그램을 파일 서버나 하위 디렉터리에 쉽게 넣을 수 있습니다. $HOME/Applications, 당신이 그렇게 좋아한다면.

하이쿠에 대하여, 패키지를 두 번 클릭한 다음 "설치"를 클릭하면 이보다 더 쉬울 수 없습니다. 패키지에 HaikuPorts에서 사용할 수 있지만 아직 설치되지 않은 종속성이 있는 경우 어떻게 되는지 궁금합니다. Linux에서는 이러한 상황에서 무엇을 해야 할지 실제로 알지 못하지만 해결책은 분명합니다. 사용자에게 종속성을 다운로드하고 설치해야 하는지 물어보세요. 바로 하이쿠가 하는 일입니다.

'sanity' 패키지를 수동으로 다운로드하고 클릭하면 패키지 관리자가 해당 종속성을 어디서 가져올 수 있는지 알고 있습니다(저장소가 시스템에 이미 등록되어 있다고 가정). 모든 Linux 배포판이 이를 수행할 수 있는 것은 아닙니다.

또 다른 방법은 파일 관리자를 사용하는 것입니다. 끌어서 놓기만 하면 됩니다. .hpkg 패키지 또는 /Haiku/system/packages (기본적으로 시스템 전체 설치의 경우) 또는 /Haiku/home/config/packages (개별 설치의 경우, 두 번 클릭하면 사용할 수 없습니다. 여기서는 "config"라는 단어가 여전히 짜증납니다. 이 경우 "설정"과 동의어입니다.) 그리고 다중 사용자라는 개념은 아직 Haiku에서는 사용할 수 없습니다(그래서 그렇게 간단한 것일 수도 있습니다. 어쩌면 다중 사용자 기능이 데스크탑 데스크탑 환경의 상황을 불필요하게 복잡하게 만들 수도 있습니다).

Haiku는 응용 프로그램뿐만 아니라 시스템 프로그램에서도 작동할 수 있기 때문에 이 범주에서 승리합니다.

GUI에서 패키지 제거

맥에서, 애플리케이션 아이콘을 휴지통으로 드래그하기만 하면 됩니다. 용이하게!

하이쿠에 대하여, 먼저 패키지를 올바른 위치에 설치하는 경우가 거의 없기 때문에 시스템에서 패키지가 있는 위치를 찾아야 합니다(시스템이 모든 작업을 수행함). 보통은 직접 살펴보셔야 할 것 같아요 /Haiku/system/packages (시스템 전체 기본 설치) 또는 /Haiku/home/config/packages ("config"가 잘못된 이름이라고 언급했나요?) 그런 다음 애플리케이션을 휴지통으로 드래그하기만 하면 됩니다.
용이하게! 그러나 나는 그렇게 말하지 않을 것입니다. 실제로 일어나는 일은 다음과 같습니다.

애플리케이션을 휴지통으로 드래그하면 이런 일이 발생합니다. /Haiku/system/packages

방금 QtQuickApp의 "Hello World" 애플리케이션을 휴지통으로 옮기려고 했습니다. 시스템 디렉터리를 이동하려고 하지 않았으나, 모든 패키지는 시스템 디렉터리에 설치되어 있으므로 패키지 제거는 불가능합니다. .hpkg 변함없이 "그 내용". 일반 사용자라면 겁을 먹고 기본으로 할당된 '취소' 버튼을 눌렀을 것입니다.

설명하다 씨. 뒤뚱뒤뚱:

이 게시물은 10년이 넘었습니다. 패키지 자체가 이동될 때만 경고가 표시되도록 구성해야 할 가능성이 높습니다. 일반 사용자는 어쨌든 이 작업을 수행할 필요가 없습니다.

좋아요, 아마도 HaikuDepot을 사용하여 이 작업을 수행해야 할까요? 패키지를 두 번 클릭합니다. /Haiku/system/packages, "제거" 버튼이 나타날 때까지 기다리고 있습니다. 아니요, "설치"만 있습니다. "제거", 당신은 어디에 있습니까?

재미삼아 이미 설치된 패키지에서 “설치”를 클릭하면 어떤 일이 일어나는지 확인해 보았습니다. 다음과 같이 밝혀졌습니다.

이미 설치된 패키지를 설치하려고 하면 이런 일이 발생합니다.

다음이 나타납니다:

이전 창에서 '변경사항 적용'을 클릭하면 다음과 같이 표시됩니다.

나는 이것이 소프트웨어 오류라고 가정합니다. 응용 프로그램에 대한 링크가 이미 있습니다. [저자는 링크를 제공하지 않았습니다. - 대략. 역자]

빠른 해결 방법: 패키지가 이미 있는 경우 "제거" 버튼을 추가하세요. /Haiku/system/packages또는 /Haiku/home/config/packages.

HaikuDepot에 설치된 패키지 목록을 보면 내 패키지가 목록에 표시되고 제거할 수 있습니다.

이 부문에서는 Mac이 승리합니다. 하지만 적절한 설정을 사용하면 Haiku의 사용자 경험이 Mac보다 더 좋아질 것이라고 상상할 수 있습니다. (개발자 중 한 명이 이렇게 평가했습니다. "C++를 조금이라도 알고 있다면 HaikuDepot에 지정된 기능을 추가하는 데 한 시간도 안 남았습니다.", 자원 봉사자가 있습니까?)

패키지에서 항목 제거

패키지가 아닌 애플리케이션 자체를 제거해 보겠습니다. .hpkg, 그것이 나온 것입니다 ( "단순한 필사자"에게는 차이가 있는지 의심됩니다).

맥에서, 사용자는 실제로 일반적으로 파일을 사용하여 작업합니다. .dmg응용 프로그램 패키지는 어디에서 왔습니까? .app. 보통 이미지 .dmg 패키지는 다운로드 디렉터리에 축적되며, 패키지는 사용자에 의해 복사됩니다. /Applications. 많은 사용자 자신이 무엇을하고 있는지 모르는 것으로 여겨지며 전 Apple 직원이이 가설을 확인했습니다. (Mac에서 마음에 들지 않는 점 중 하나입니다. 예를 들어 AppImage의 경우 애플리케이션과 해당 애플리케이션이 포함된 패키지 사이에 차이가 없습니다. 아이콘을 휴지통으로 드래그하면 됩니다. 그게 전부입니다. 쉽습니다!)

하이쿠에 대하여, 사이에도 구분이 있습니다. apps/ и packages/, 그래서 이것이 사용자에게 더 명확해졌는지 의심됩니다. 하지만 다음에서 애플리케이션을 드래그하면 어떻게 될까요? apps/ 장바구니에 추가:

파일에서 가져온 애플리케이션을 제거하려고 하면 이런 일이 발생합니다. .hpkg

기술적으로는 정확하지만(어쨌든 응용 프로그램은 처음에 읽기 전용 파일 시스템에서 호스팅됨) 사용자에게 특별히 유용하지는 않습니다.

빠른 해결 방법: 대신 GUI를 사용하여 삭제하는 것이 좋습니다. .hpkg

재미삼아 Alt+D를 눌러 애플리케이션을 복제해 보았습니다. "읽기 전용 볼륨의 개체를 이동하거나 복사할 수 없습니다."라는 메시지를 받았습니다. 그리고 모두 왜냐하면 /system (게다가 /system/packages и /system/settings)는 packagefs 마운트 지점입니다(출력에 어떻게 나타나는지 기억하세요). df?). 불행하게도 명령의 출력은 mount (이전 기사 중 하나에서 언급했듯이) 상황을 명확하게 설명하지 않습니다. mountvolume 찾고 있는 것이 표시되지 않습니다(분명히 루프를 통해 마운트된 패키지입니다). .hpkg "볼륨"으로 간주되지 않음), 대체 명령도 잊어버렸습니다.

AppImage를 제외하고는 이 카테고리에서 우승한 사람이 없습니다(그러나 이는 솔직히 말해서 편향된 의견입니다). 그러나 조정 후에는 Haiku의 사용자 경험이 Mac보다 더 좋아질 것이라고 상상할 수 있습니다.

참고: "섹션"과 관련하여 "볼륨"이 무엇인지 알아야 합니다. 이는 아마도 "폴더"와 "디렉토리"의 관계와 유사할 것입니다. 대부분의 디렉터리는 파일 관리자에 폴더로 표시되지만 전부는 아닙니다(예: 패키지는 파일로 처리됨). 이런 종류의 전시가 나를 공식적인 괴짜로 만드는가?

패키지 내용을 다른 시스템에 복사

맥에서, 나는 어리석게 패키지를 끌고 있습니다 .app, 종속성은 패키지 내부에 있으므로 함께 이동합니다.

하이쿠에 대하여, 애플리케이션을 드래그했지만 종속성이 전혀 처리되지 않습니다.

빠른 해결 방법: 종속성이 있는 경우 전체 `.hpkg 패키지를 드래그하는 것이 좋습니다.

이 범주에서는 Mac이 확실히 승리합니다. 적어도 나에게는 그들의 패러다임을 사랑하는 사람이다. 하이쿠로 복사해야지 .hpkg 응용 프로그램 대신 시스템에서 이것을 제공하지 않습니다 ...

모든 종속성이 포함된 패키지 다운로드

모든 기계가 항상 네트워크에 연결되어 있는 것은 아닙니다. 반대로 일부 컴퓨터(예, 최신 Windows, Mac 및 Linux)는 이를 잊어버립니다. 예를 들어, 인터넷 카페에 가서 이동식 드라이브에 소프트웨어를 다운로드하고 이 드라이브를 집 컴퓨터에 삽입한 다음 모든 것이 제대로 작동하는지 확인하는 것이 중요합니다. [위험한 사람, Windows에서 이 작업을 수행... - 대략. 역자].

결과적으로 평소보다 좀 더 자주 Windows 및 Linux에 대한 종속성이 충족되지 않는 경향이 있습니다.

맥에서 이것은 일반적으로 하나의 파일이므로 다운로드만 하면 됩니다. .dmg. 대부분의 경우 기본적으로 MacOS 자체에서 제공하는 것 외에는 종속성이 없습니다. 단, 적절한 실행 환경이 필요한 복잡한 애플리케이션(예: java)은 예외입니다.

하이쿠에 대하여 패키지 다운로드 .hpkg 예를 들어, Java의 동일한 애플리케이션만으로는 충분하지 않을 수 있습니다. 왜냐하면 Java가 대상 시스템에 존재할 수도 있고 존재하지 않을 수도 있기 때문입니다. 특정 패키지에 대한 모든 종속성을 다운로드하는 방법이 있습니까? .hpkg, Haiku에 기본적으로 설치되어 모든 Haiku 시스템에 있어야 하는 것 외에?

Mac은 이 부문에서 근소한 차이로 승리했습니다.

댓글 씨. 뒤뚱뒤뚱:

애플리케이션의 모든 종속성을 패키지 세트로 수집하는 프로그램을 작성하려면 .hpkg 하이쿠의 내부 작동 방식에 익숙한 사람에게는 약 15분이면 충분합니다. 실제로 필요한 경우 이에 대한 지원을 추가하는 것은 그리 어렵지 않습니다. 하지만 나에게 이것은 드문 상황이다.

이 시리즈의 다음 기사가 나올 때까지 숨을 참아보자.

패키지를 별도의 위치로 이동

앞서 쓴 것처럼 패키지를 배치하고 싶습니다. .hpkg (글쎄, 또는 그 일부)를 부팅 볼륨(루트 파티션)의 일반적인 위치와는 별도로 특별한 위치에 저장합니다. 일반적인(그렇게 이론적이지는 않은) 경우, 그 이유는 내 (내장) 디스크의 크기에 관계없이 디스크의 여유 공간이 지속적으로 부족하기 때문입니다. 그리고 일반적으로 내 애플리케이션이 있는 외부 드라이브나 네트워크 공유를 연결합니다.

맥에서 패키지를 옮기는 중이에요 .app Finder의 이동식 드라이브나 네트워크 디렉터리에 저장하면 됩니다. 평소처럼 부팅 볼륨에서 두 번 클릭하여 응용 프로그램을 열 수 있습니다. 단지!

하이쿠에 대하여, 내가 말했듯이 이것은 내 움직임을 통해 달성될 수 있습니다. .hpkg 패키지를 이동식 드라이브나 네트워크 디렉터리에 저장하지만 시스템에 마운트하려면 콘솔에서 문서화되지 않은 일부 명령을 사용해야 합니다. GUI만 사용하여 이 작업을 수행하는 방법을 모르겠습니다.

이 부문에서는 Mac이 승리합니다.

씨에 따르면 뒤뚱뒤뚱:

이는 일반적인 사용을 기반으로 한 최적화입니다. 여러 사용자의 요구가 있는 경우 이를 구현합니다. 어쨌든 제XNUMX자 구현 가능성이 있습니다.

이에 대해서는 다음 기사에서 이야기하겠습니다.

네트워크 디렉터리에 관해 말하면 로컬 컴퓨터에 복사하거나 로컬 네트워크에서 직접 실행할 수 있는 간단하고 검색 가능하며 네트워크 전체에 적용되는 응용 프로그램(예: Zeroconf)이 있으면 좋을 것입니다(LAN 파티인 것 같습니다). 물론 개발자는 다음을 통해 선택 해제할 수 있습니다. app_flags.

hpkg 시스템과 GUI의 통합에 대한 최종 보고서

나는 주로 통합이 상대적으로 새로웠기 때문이라고 생각합니다. .hpkg GUI는 아직 부족한 점이 많습니다. 어쨌든 UX 측면에서 개선할 수 있는 점이 몇 가지 있습니다.

한 가지 더: 커널 디버그 랜드

예를 들어, 커널 패닉 중에 명령을 입력할 수 있다면 좋을 것입니다. syslog | grep usb. 음, Haiku에서는 Kernel Debug Land 덕분에 가능합니다. 커널 패닉에 빠지지 않고 모든 것이 정상적으로 작동한다면 어떻게 이 마법이 작동하는지 볼 수 있습니까? Alt+PrintScn+D(디버그 니모닉)를 누르면 쉽습니다. 나는 즉시 기억한다 프로그래머의 키, 원래 Macintosh 개발자가 디버거에 들어갈 수 있도록 허용했습니다(물론 디버거가 설치된 경우).

결론

나는 Haiku 시스템의 정교함은 작업 환경에 명확한 초점을 두고 시스템의 모든 계층에 액세스할 수 있는 하나의 소규모 팀에 의해 작업이 수행된다는 사실에서 비롯된다는 점을 이해하기 시작했습니다.
Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu의 세계와는 뚜렷한 대조를 이룹니다. 여기서는 추상화가 추상화 위에 있고 목발을 짚고 구동할 정도로 모든 것이 작은 조각으로 나누어져 있습니다.
시스템이 어떻게 되어 있는지에 대한 이해도 있었습니다. .hpkg 기존 패키지 관리자, Snappy, Flatpak, AppImage, 심지어 btrfs의 모범 사례를 결합하고 이를 Mac의 "그냥 작동하는" 접근 방식과 혼합합니다.

마치 내 머릿속에서 무언가가 "전환"된 것 같았고 시스템이 어떻게 작동하는지 이해했습니다. .hpkg 그녀를 보는 것만으로도 굴러가는 법을 알고 있습니다. 하지만 그것은 내가 아니라 시스템의 아름다움과 단순함입니다. 이 중 대부분은 원래 Mac의 정신에서 영감을 받았습니다.

예, 브라우저 탐색이 불안정하고 달팽이처럼 실행될 수 있고, 응용 프로그램이 부족할 수 있으며(Gtk, Electron 없음 - 개발자는 정교함과 잘 어울리지 않는다고 결론 내림), 비디오 및 3D 가속이 전혀 없을 수 있지만 여전히 이 시스템이 좋아요. 결국 이러한 것들은 수정될 수 있으며 조만간 나타날 것입니다. 시간 문제일 뿐이고 약간의 적목 현상도 있을 수 있습니다.

도움을 드릴 수는 없지만 이제부터 시작될 것 같아요 데스크탑에서의 하이쿠의 해.

무작위 문제

이미 요청이 있을 수도 있습니다. 아니면 열어야 합니까?

• BeScreenCapture는 Peek처럼 GIF로 내보낼 수 있어야 합니다. 이는 이미 Haiku에 사용 가능한 ffmpeg를 사용하여 수행할 수 있습니다. 의뢰.
• 스크린샷 소프트웨어가 모달 창을 캡처하지 못하고 대신 전체 화면을 캡처합니다.
• WonderBrush의 자르기 도구를 사용하여 스크린샷을 자른 다음 결과를 파일에 저장할 수 없습니다
• 저는 하이쿠의 손 모양 커서를 별로 좋아하지 않지만 따뜻한 향수를 불러일으키는 느낌과 관련이 있다고 생각합니다. 이는 Krita에서 자르기 도구를 사용할 때 특히 짜증스럽습니다. 자르기가 부정확해지기 때문입니다(이 문서의 모달 대화 상자 스크린샷 참조). 십자형 커서가 있으면 정말 좋을 것 같습니다. 의뢰.

직접 시도해 보세요! 결국 Haiku 프로젝트는 DVD 또는 USB에서 부팅하기 위한 이미지를 제공합니다. 매일. 설치하려면 이미지를 다운로드하고 다음을 사용하여 플래시 드라이브에 쓰십시오. 동판 화공

질문있으세요? 러시아어로 여러분을 초대합니다 전보 채널.

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

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

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

출처 : habr.com