TL; DR: Haiku, özellikle PC'ler için tasarlanmış bir işletim sistemidir, dolayısıyla masaüstü ortamını diğerlerinden çok daha iyi hale getiren çeşitli püf noktaları vardır. Peki nasıl çalışıyor?
Beklenmedik derecede iyi bir sistem olan Haiku'yu keşfettim. Özellikle Linux masaüstü ortamlarıyla karşılaştırıldığında ne kadar sorunsuz çalıştığına hâlâ hayret ediyorum. Bugün kaputun altına bir göz atacağım. Derinlemesine bir anlayış için gerekli olduğu yerde orijinal Macintosh, Mac OS X ve Linux masaüstü ortamlarıyla (freedesktop.org'dan XDG standardı) karşılaştırmalar yapacağım.
ELF dosyalarındaki kaynaklar
Dün IconOMatic'in simgeleri ELF yürütülebilir dosyalarındaki rdef kaynaklarına kaydedebildiğini öğrendim. Bugün bunun gerçekten nasıl çalıştığını görmek istiyorum.
Kaynaklar? itibaren , Macintosh Finder'ın orijinal yazarı ve Macintosh Resource Manager'ın "babası":
Geleneksel kodlamanın katı doğasından endişe duyuyorum. Benim için herhangi bir şeyi dinamik olarak değiştirme yeteneği olmayan, kod içinde donmuş bir uygulama fikri en çılgın vahşettir. Çalışma zamanında mümkün olduğu kadar değişiklik mümkün olmalıdır. Elbette uygulama kodunun kendisi değiştirilemez, ancak kodu yeniden derlemeden mutlaka bir şeyler değiştirilebilir mi?
Orijinal Macintosh'ta bu dosyaların bir "veri bölümü" ve bir "kaynak bölümü" olmasını sağladılar; bu da simgeler, çeviriler ve benzeri şeyleri kaydetmeyi inanılmaz derecede kolaylaştırdı. yürütülebilir dosyalarda.
Mac'te bu kullanılır , kaynakları aniden düzenlemek için kullanılan grafiksel bir program.
Orijinal Macintosh'ta ResEdit
Sonuç olarak simgeleri, menü öğelerini, çevirileri vb. düzenlemek mümkün hale geldi. yeterince kolay, ancak yine de uygulamalarla birlikte "seyahat ediyorlar".
Her durumda, bu yaklaşımın büyük bir dezavantajı vardı: yalnızca Apple dosya sistemlerinde çalışıyordu; bu, Apple'ın Mac OS X'e geçerken "kaynak bölümünü" terk etmesinin nedenlerinden biriydi.
Mac OS X'te Apple, dosya sisteminden bağımsız bir çözüm istiyordu, bu nedenle paketler kavramını (NeXT'den), yani dosya yöneticisi tarafından dizinler yerine dosyalar gibi "opak nesneler" olarak değerlendirilen dizinleri benimsediler. biçimindeki bir uygulamaya sahip herhangi bir paket .app diğer şeylerin yanı sıra bir dosya var Info.plist (bir çeşit Apple'ın JSON veya YAML eşdeğerinde) uygulama meta verilerini içerir.
Mac OS X uygulama paketindeki Info.plist dosyasının anahtarları.
Simgeler, kullanıcı arayüzü dosyaları ve diğerleri gibi kaynaklar pakette dosyalar olarak saklanır. Konsept aslında NeXT'deki köklerine geri döndü.
1.0'da NeXTSTEP 1989'da Mathematica.app: terminalde bir dosya dizini olarak görünür, ancak grafiksel dosya yöneticisinde tek bir nesne olarak görünür.
Haiku'nun dayandığı kavramlar olan BeOS'a dönelim. Geliştiricileri, PEF'ten (PowerPC) ELF'ye (x86) (Linux'ta kullanılanla aynı) geçiş yaparken, ELF dosyalarının sonuna bir kaynak bölümü eklemeye karar verdiler. Kendi uygun ELF bölümünü kullanmadı, sadece ELF dosyasının sonuna eklendi. Program sonucunda strip ve binutils'ten diğerleri bunun farkında olmadan onu kestiler. Bu nedenle BeOS'ta bir ELF dosyasına kaynak eklerken onu Linux araçlarıyla değiştirmemek daha iyidir.
Şimdi Haiku'ya ne oluyor? Temelde aşağı yukarı aynı.
Teorik olarak kaynakları ELF'in istenilen bölümüne yerleştirmek mümkün olacaktır. irc.freenode.net'teki #haiku kanalındaki geliştiricilere göre:
ELF olsaydı bu bölüm daha anlamlı olurdu... Bunu bu şekilde yapmamamızın tek nedeni, BeOS'ta da bunu yapmış olmamızdır."
Ve artık bunu değiştirmenin bir anlamı yok.
Büyük resim
Kaynaklar yapılandırılmış bir "kaynak" formatında yazılır: esasen boyutları ve ardından içerikleri olan kaynakların bir listesi. hatırladım .
Haiku'da kaynaklar nasıl kontrol edilir? ResEdit gibi bir şey var mı?
Göre :
Uygulama paketinde sağlanan kaynakları görüntülemek için yürütülebilir dosyayı aşağıdaki gibi bir programa sürükleyebilirsiniz: . Ayrıca terminale gidip komutu çalıştırabilirsiniz.
listres имя_файла.
Resourcer HaikuDepot'ta mevcut, ancak benim için çöküyor.
ELF dosyalarındaki kaynaklar nasıl yönetilir? Kullanma rsrc и rdef. rdef dosyalar şurada toplanır rsrc. Dosya rdef düz metin biçiminde depolanır, bu nedenle üzerinde çalışmak çok daha kolaydır. Dosya formatı rsrc ELF dosyasının sonuna eklenir. Oynamayı deneyelim:
~> 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 licenseProgramı kullanabilirsiniz xres kontrol ve kontrol için:
/> 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.
(...)Tamam, deneyelim mi?
/> 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_VERSIONKaynaklar ve format hakkında daha fazla bilgi rdef okuyabilir .
Standart kaynak türleri
Kaynaklara her şeyi koyabilmenize rağmen tanımlanmış birkaç standart tür vardır:
app_signature: Dosya açma eşlemesi, başlatma, IPC vb. için MIME uygulama türü.app_name_catalog_entry: Uygulama adı genellikle İngilizce olduğundan çevrilmiş adların bulunduğu yerleri belirtebilirsiniz, böylece farklı dillerdeki kullanıcılar istenirse çevrilmiş uygulama adını görecektir.app_version: tam olarak ne düşündünapp_flags: gösterirregistrarbaşvurunun nasıl işleneceği. Bence göründüğünden daha fazlası var. Örneğin, varB_SINGLE_LAUNCH, kullanıcı her talep ettiğinde sistemi yeni bir uygulama süreci başlatmaya zorlar (aynı prensip Linux'taki çoğu uygulama için kullanılır). Yemek yemekB_MULTIPLE_LAUNCHişlemin yürütülmesine neden oluyor her dosya. Sonunda varB_EXCLUSIVE_LAUNCH, kullanıcılar onu ne sıklıkta başlatırsa başlatsın sistemi aynı anda yalnızca bir işlemi başlatmaya zorlar (örneğin, Firefox Linux'ta bu şekilde çalışır; aynı sonuç Qt uygulamalarında bu işlevi kullanarak elde edilebilir) ). ile uygulamalarB_EXCLUSIVE_LAUNCHKullanıcı onları tekrar çalıştırmayı denediğinde bilgilendirilirler: örneğin, kullanıcının kendi yardımıyla açmak istediği dosyanın yolunu alırlar.vector_icon: Vektör uygulama simgesi (BeOS'un vektör simgeleri yoktu; çoğu uygulamanın yürütülebilir dosyalarında bunun yerine iki raster simgesi vardı).
Elbette istediğiniz kimlik ve türde kaynaklar ekleyebilir ve ardından bunları uygulamanın kendisinde veya sınıfı kullanarak diğer uygulamalarda okuyabilirsiniz. BResources. Ama önce ikonların büyüleyici konusuna bakalım.
Haiku tarzında vektör simgeler
Elbette sadece Haiku en iyi simge formatını seçmedi; bu kısımda Linux masaüstü ortamlarındaki durum ideal olmaktan çok uzak:
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.cacheBuna baktığınızda onun nasıl bir parça olduğunu zaten hissedebiliyorsunuz.
Tabii ki, anlayabileceğiniz gibi vektör simgeleri içeren ölçeklenebilir bir şey var. O zaman neden başka bir şey var? Çünkü vektör grafiklerinin küçük boyutlarda çizilmesi sonucu idealden daha az olabilir. Farklı boyutlar için optimize edilmiş farklı seçeneklere sahip olmak istiyorum. Linux masaüstü ortamlarında bu, farklı boyutlardaki simgelerin dosya sistemi boyunca dağıtılmasıyla elde edilir.
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.pngLütfen unutmayın: Firefox'un farklı sürümleri kavramı yoktur. Dolayısıyla bir uygulamanın birden fazla versiyonunun sistemde bulunması durumunu sağlıklı bir şekilde ele almak mümkün değildir.
Farklı sürümlerde farklı Firefox simgeleri. Linux'ta bunu çeşitli koltuk değnekleri olmadan halletmek şu anda mümkün değil.
Mac OS X bunu biraz daha ustaca ele alıyor:
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.icnsBir dosyanın olduğu görülebilir firefox.icns paketin içinde Firefox.app, aynı uygulamanın farklı sürümlerinin farklı simgelere sahip olması için tüm boyutları içerir.
Çok daha iyi! Simgeler uygulamayla birlikte seyahat eder, tüm kaynaklar tek bir dosyadadır.
Haiku'ya dönelim. Akıllara durgunluk veren bir çözüm, istisna yok. Buna göre :
Küçük boyutlar ve hızlı işleme için yüksek düzeyde optimize edilmiş özel bir HVIF formatı geliştirildi. Bu nedenle simgelerimiz çoğunlukla raster veya yaygın olarak kullanılan SVG formatından çok daha küçüktür.
Ve hala optimize edilmiş durumdalar:
Diğer formatlarla karşılaştırıldığında HVIF'deki simge boyutları.
Fark büyüklük sırasına göre!
Ancak sihir burada bitmiyor. Aynı HVIF, bir vektör formatı olmasına rağmen görüntülenen boyuta bağlı olarak farklı ayrıntı seviyeleri gösterebilir.
İşleme boyutuna bağlı olarak farklı ayrıntı seviyeleri (LOD)
Şimdi dezavantajlarına gelince: SVG'yi alıp ImageMagick'e atıp bir gün sonra yapamazsınız; HVIF formatında bir simge oluşturmak için birkaç döngüden geçmeniz gerekir. açıklamalar. Ancak IconOMatic, SVG'yi oldukça kusurlu bir şekilde içe aktarabilir; SVG ayrıntılarının yaklaşık %90'ı belli bir olasılıkla içe aktarılır, geri kalan %10'un manuel olarak yapılandırılması ve değiştirilmesi gerekecektir. HVIF'in büyüsünü nasıl yaptığı hakkında daha fazlasını okuyun blogda
Uygulamaya simge ekleme
Artık oluşturulan pakete bir simge ekleyebilirim Alınan tüm bilgileri dikkate alarak.
Şu anda "Merhaba Dünya" QtQuickApp'im için kendi simgemi çizmeye pek hevesli olmadığım için, onu Qt Creator'dan çıkarıyorum.
/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 CreatorSimgenin kopyalanıp kopyalanmadığını kontrol edelim:
/Haiku/home> xres -l /Haiku/home/QtQuickApp/QtQuickApp/Haiku/home/QtQuickApp/QtQuickApp
resources:type ID size name
------ ----------- ----------- --------------------
'VICN' 101 152238 BEOS:ICONİyi görünüyor, ancak yeni simge kopyalandığında neden görünmüyor?
Kopyalanan VICN:101:BEOS:ICON'lar henüz dosya yöneticisinde uygulama simgesi olarak kullanılmıyor
Ne kaçırdım?
Geliştirici yorumu:
Bir dosya oluşturmamız gerekiyor
rdeftüm kaynaklarla birlikte komutu yürütünrc имя.rdef, bu dosyayı yaratacaktır.rsrc. Daha sonra komutu çalıştırmanız gerekirresattr -o имя_бинарника имя.rsrc. En azından komut dosyalarıma simgeler eklemek için bunun gibi komutları kullanıyorum.
Ben bir özellik değil, bir kaynak yaratmak istedim. Gerçekten kafam karıştı.
Dosya sistemini kullanarak akıllı önbelleğe alma
ELF niteliklerinin açılması ve okunması yavaştır. Yukarıda yazdığım gibi simge dosyanın kendisinde kaynak olarak yazılmıştır. Bu yöntem daha güvenilirdir ve başka bir dosya sistemine kopyalarken hayatta kalmanızı sağlar. Ancak daha sonra dosya sistemi özniteliğine de kopyalanır; örneğin BEOS:ICON. Bu yalnızca BFS gibi belirli dosya sistemlerinde çalışır. Sistem tarafından gösterilen simgeler (İzleyici ve Masaüstü Çubuğu'nda) bu genişletilmiş özellikten okunur çünkü bu çözüm hızlı çalışır. Bazı yerlerde (hızın önemli olmadığı yerlerde, örneğin tipik bir "Hakkında" penceresi), sistem, simgeyi doğrudan dosyadaki kaynaktan alır. Ama bu son değil. Mac'te kullanıcıların uygulamaların, dizinlerin, belgelerin simgelerini kendi simgeleriyle değiştirebileceğini unutmayın, çünkü Mac'te bu "önemli" şeyleri yapmak mümkündür, örneğin . Haiku'da, kaynağı (dosyadaki) uygulamayla birlikte gelen orijinal simge olarak ve özniteliği (BFS dosya sisteminde) kullanıcının istediği zaman değişiklik yapmasına olanak tanıyan bir şey olarak düşünmelisiniz (ancak, ipucu, simgenin üstüne özel bir simge eklemek için kullanılan GUI isteğe bağlıdır (henüz varsayılan olarak uygulanmamıştır).
Dosya sistemi özniteliklerini kontrol etme
Ile resaddr Dosya sistemi niteliklerini kontrol etmek ve ayarlamak mümkündür.
/> 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.
(...)Esasen (güvenilir) kaynaklar ve (hızlı) dosya sistemi nitelikleri arasında ileri geri dönüşümü gerçekleştiren "yapıştırıcıdır". Sistem kaynakları almayı beklediği ve kopyalamayı otomatik olarak yaptığı için artık bu konuda endişelenmeyeceğim.
hpkg paketlerinin büyüsü
Şu anda (çoğunlukla) paketler Haiku'daki programları edinmek için kullanılıyor .hpkg. Basit ismine aldanmayın: .hpkg formatı, karşılaştığınız benzer adlara sahip diğer formatlardan tamamen farklı çalışır, gerçek süper güçlere sahiptir.
Geleneksel paket formatlarında şu gerçek yüzünden uzun süre üzülmüştüm: Bir şeyi (paket) indiriyorsunuz ve sisteme başka bir şey yükleniyor (paketin içindeki dosyalar). Bir paketi geleneksel şekilde kurarken dosyaları yönetmek (örneğin silmek) oldukça zordur. Ve hepsi paketin içeriği nedeniyle dosya sistemi boyunca dağılmışOrtalama bir kullanıcının yazma erişimine sahip olamayabileceği yerler de dahil. Bu, bütün bir program sınıfının ortaya çıkmasına neden olur - paket yöneticileri. Ancak halihazırda kurulu olan yazılımı örneğin başka bir makineye, çıkarılabilir diske veya dosya sunucusuna aktarmak tamamen imkansız olmasa da daha da zor hale gelir. Tipik bir Linux tabanlı sistemde kolaylıkla birkaç yüz binden milyonlarcaya kadar bireysel dosya bulunabilir. Söylemeye gerek yok, örneğin bir sistemi ilk kez kurarken, normal paketleri kurarken, güncellerken ve kaldırırken ve önyükleme birimini (kök bölüm) başka bir ortama kopyalarken bu hem kırılgan hem de yavaştır.
Son kullanıcı uygulamaları için kısmi bir destek olan AppImage projesi üzerinde çalışıyorum. Bu, bir uygulamayı ve onun tüm bağımlılıklarını, uygulama başlatıldığında bağlanan tek bir dosya sistemi görüntüsünde toplayan bir yazılım dağıtım formatıdır. Aynı ImageMagick birdenbire ölümlüler tarafından bir dosya yöneticisinde yönetilen tek bir dosyaya dönüştüğü için işleri önemli ölçüde basitleştirir. Önerilen yöntem, projenin adından da anlaşılacağı gibi yalnızca yazılım için işe yarıyor ve aynı zamanda Linux için yazılım dağıtımında yer alan insanlar oku her zaman bana doğrulttukları için kendi sorunları da var.
Haiku'ya dönelim. Geleneksel paket sistemleri ile görüntü tabanlı yazılım teslimi arasında en uygun dengeyi bulmak mümkün oldu mu? Onun paketleri .hpkg aslında sıkıştırılmış dosya sistemi görüntüleri. Sistem önyüklendiğinde, çekirdek tüm kurulu ve aktif paketleri yaklaşık olarak aşağıdaki çekirdek mesajlarıyla bağlar:
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"Harika, değil mi? Orada kalın, daha da serin olacak!
Çok özel bir paket var:
KERN: package_daemon [16040020: 924] active package: "haiku-r1~beta1_hrev53242-1-x86_64.hpkg"Çekirdek dahil oldukça minimalist bir işletim sistemi içerir. İster inanın ister inanmayın, çekirdeğin kendisi bile önyükleme biriminden (kök bölüm) kaldırılmaz, paketten dikkatlice yerine yüklenir. .hpkg. Vay! Haiku'nun genel karmaşıklığının ve tutarlılığının bir kısmının, çekirdek ve çekirdek kullanıcı alanından paket yönetimi ve çalışma zamanı altyapısına kadar tüm sistemin tek bir ekip tarafından işbirliği içinde geliştirilmesi gerçeğinden kaynaklandığını düşündüğümden daha önce bahsetmiştim. Linux'ta böyle bir şeyi yürütmek için kaç farklı grup ve ekibin gerektiğini bir düşünün [PuppyLinux projesini hayal ediyorum - yakl. çevirmen]. Daha sonra bu yaklaşımın dağıtımlara benimsenmesinin ne kadar süreceğini hayal edin. Diyorlar ki: Basit bir problemi alın, onu farklı icracılar arasında bölün, o kadar karmaşık hale gelecektir ki artık onu çözmek mümkün olmayacaktır. Bu durumda Haiku gözlerimi açtı. Şu anda Linux'ta olan şeyin tam olarak bu olduğunu düşünüyorum (Linux bu durumda Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu yığını için ortak bir terimdir).
hpkg kullanarak sistemi geri alma
Aşağıdaki durum ne sıklıkla ortaya çıkıyor: Güncelleme başarılı oldu ve sonra bir şeyin olması gerektiği gibi çalışmadığı ortaya çıktı? Geleneksel paket yöneticilerini kullanırsanız, sistemin durumunu yeni paketler kurulmadan önceki bir noktaya döndürmek zordur (örneğin, bir şeylerin ters gitmesi durumunda). Bazı sistemler, dosya sistemi anlık görüntüleri biçiminde geçici çözümler sunar, ancak bunlar oldukça hantaldır ve tüm sistemlerde kullanılmaz. Haiku bunu paketleri kullanarak çözüyor .hpkg. Sistemde paketler değiştiğinde eski paketler silinmez, ancak sistemde aşağıdaki gibi alt dizinlerde saklanır. /Haiku/system/packages/administrative/state-<...>/ sürekli. Tamamlanmamış işlemler verilerini alt dizinlerde saklar /Haiku/system/packages/administrative/transaction-<...>/.
içindekiler /Haiku/system/packages/administrative. "Durum..." dizinleri aktif paketlerin adlarını içeren metin dosyalarını içerir ve "işlem..." dizinleri paketlerin kendisini içerir.
"Eski aktif durum", yani. liste .hpkg Değişikliklerden önce aktif olan paketler, dosya yöneticisindeki her işlemden sonra bir metin dosyasına kaydedilir /Haiku/system/packages/administrative/state-<...>/activated-packages. Benzer şekilde bir metin dosyasına yeni bir “aktif durum” yazılır /Haiku/system/packages/administrative/activated-packages.
Rehber /Haiku/system/packages/administrative/state-<...>/ yalnızca bu durumdaki etkin paketlerin listesini içeren bir metin dosyası içerir (paketlerin kaldırılmadan kurulması durumunda) ve paketler kaldırılmış veya güncellenmişse, durum dizini paketlerin eski sürümlerini içerir.
Sistem önyüklendiğinde, paket listesine göre paketleri etkinleştirme (bağlama) kararı verilir. Bu kadar basit! İndirme sırasında bir şeyler ters giderse indirme yöneticisine farklı, daha eski bir liste kullanmasını söyleyebilirsiniz. Sorun çözüldü!
Haiku indiricisi. Her giriş noktası karşılık gelen bir "aktif durumu" görüntüler
Basit metin dosyalarının "etkin durum" listesi olarak anlaşılması kolay adlara sahip olması yaklaşımını seviyorum .hpkg. Bu, insanlar için değil makineler için üretilmiş olmakla tam bir tezat oluşturuyor. dosya sistemindeki OSTree veya Flatpak'tan (Microsoft GUID ile aynı seviyede).
Zamandaki her nokta için aktif paketlerin listesi
Yapılandırma verileri
Görünüşe göre katalogda /Haiku/system/packages/administrative/writable-files paketler için yapılandırma dosyalarını içerir, ancak bunlar yazılabilir. Sonuçta, hatırladığınız gibi, .hpkg salt okunur olarak monte edilmiştir. Bu yüzden bu dosyaların yazılmadan önce paketlerden kopyalanması gerekir. Anlamı var.
.hpkg sistemi için GUI entegrasyonu
Şimdi bu parlak çantaların nasıl olduğunu görelim .hpkg kullanıcının çalışma ortamına (UX) entegrasyonla başa çıkın. Sonuçta Haiku kişisel kullanıma yöneliktir. Kişisel olarak kullanıcı deneyimini paketlerle karşılaştırırken çıtayı yükseğe koyuyorum .app Macintosh'ta aynı deneyime sahip .hpkg. Durumu Linux'taki çalışma ortamlarıyla karşılaştırmayacağım bile çünkü diğerleriyle karşılaştırıldığında kesinlikle berbat.
Aklıma şu senaryolar geliyor:
- Bir paketin içeriğini görüntülemek istiyorum
.hpkg - Bir paket yüklemek istiyorum
- Paketi kaldırmak istiyorum
- Sisteme bir paketin parçası olarak gelen bir şeyi kaldırmak istiyorum
- Sisteme bir paketin parçası olarak gelen bir şeyi kopyalamak istiyorum
- Her Haiku kurulumunun parçası olmayabilecek bir paketin tüm bağımlılıklarını indirmek istiyorum (örneğin, internet erişimi olmayan, fiziksel olarak yalıtılmış bir makinem var.)
- Paketlerimi (veya bir kısmını) önyükleme biriminden (kök bölüm) ayrı olarak başka bir konuma ayrı ayrı taşımak istiyorum (çünkü örneğin üzerinde yeterli alanım yok).
Bu, günlük işlerimdeki önemli vakaların çoğunu kapsamalıdır. Peki, başlayalım.
Paket içeriğini kontrol etme
na Mac Paketi açmak ve içeriğini Finder'da görüntülemek için pakete sağ tıklıyorum. Sonuçta gerçekte bu sadece gizlenmiş bir dizin! (Paketler olduğunu biliyorum .pkg sistemin uygulama olmayan bir kısmı için, ancak sıradan kullanıcılar çoğu zaman bunlarla etkileşime girmez).
Haiku'da Paketin üzerine sağ tıklayıp, içindekileri görmek için "İçindekiler"e tıklıyorum. Ancak burada, çift tıklatarak açma olanağı olmayan dosyaların yalnızca bir listesi var.
Paketi (geçici olarak) monte etmenin bir yolu olsaydı çok daha iyi olurdu .hpkg bir dosya yöneticisi aracılığıyla görüntülenebilir ve kullanıcının uygulama ayrıntıları konusunda endişelenmesine gerek kalmaz. (Bu arada açabilirsiniz .hpkg paket Expander, diğer herhangi bir arşiv gibi paketini açabilir).
HaikuDepot'un arayüzü paket dosyalarının bir listesini görüntülemenize izin verir, ancak içeriği örneğin README.md'ye çift tıklayarak görüntülemenin bir yolu yoktur.
Mac bu kategoride kazanıyor ancak istediğiniz HaikuDepot işlevselliğini eklemek çok zor olmasa gerek.
GUI aracılığıyla paket yükleme
na Mac, çoğu disk görüntüsü .dmg paketler içerir .app. Disk görüntüsüne çift tıklayın ve ardından paketi örneğin sürükleyerek kopyalayın. /Applications Finder'da. Benim için bunu söylemeye gerek yok ama bazı yeni başlayanların bununla baş edemeyebileceğini duydum. Varsayılan olarak Apple, sistem çapında bir dizin "önerir" /Applications (NeXT'te hem bireysel hem de ağa bağlıydı), ancak uygulamalarınızı kolayca bir dosya sunucusuna veya bir alt dizine yerleştirebilirsiniz. $HOME/Applications, eğer bu şekilde hoşlanıyorsan.
Haiku'da, pakete çift tıklayın, ardından “Yükle”ye tıklayın, daha kolay olamazdı. Bir paketin HaikuPorts'ta mevcut olan ancak henüz kurulmamış bağımlılıkları varsa ne olacağını merak ediyorum. Linux'ta bu durumda ne yapacaklarını gerçekten bilmiyorlar, ancak çözüm açık - kullanıcıya bağımlılıkları indirip yüklemeleri gerekip gerekmediğini sorun. Tam olarak Haiku'nun yaptığı şey.
'Sağlık' paketini manuel olarak indirdim ve üzerine tıkladım, paket yöneticisi bağımlılıklarını nereden alacağını biliyor (depoların sistemde zaten kayıtlı olduğunu varsayarak). Her Linux dağıtımı bunu yapamaz.
Başka bir yol da dosya yöneticisi kullanmaktır; yalnızca sürükleyip bırakın .hpkg paket veya içinde /Haiku/system/packages (varsayılan olarak sistem çapında kurulum için) veya /Haiku/home/config/packages (bireysel kurulum için; çift tıklandığında kullanılamaz - bu yerde benim için "ayarlar" ile eşanlamlı olan "config" kelimesi beni hala rahatsız ediyor. Ve birden fazla kullanıcı kavramı henüz Haiku için mevcut değil (muhtemelen bu kadar basit olmasının nedeni budur - bilmiyorum, belki çok kullanıcılı özellikler bir masaüstü masaüstü ortamı için işleri gereksiz yere karmaşık hale getirebilir).
Haiku bu kategoride sadece uygulamalarla değil sistem programlarıyla da çalışabildiği için kazanıyor.
Bir paketi GUI'den kaldırma
na Mac, uygulama simgesini çöp kutusuna sürüklemeniz gerekiyor, hepsi bu. Kolayca!
Haiku'da, öncelikle paketin sistemde nerede bulunduğunu bulmanız gerekir, çünkü onu nadiren doğru yere kurarsınız (sistem her şeyi yapar). Genellikle içeri bakmanız gerekir /Haiku/system/packages (sistem çapında varsayılan kurulumla) veya /Haiku/home/config/packages (“config”in yanlış bir isim olduğunu söylemiş miydim?). Daha sonra uygulama çöp kutusuna sürüklenir, hepsi bu.
Kolayca! Ancak bunu söylemeyeceğim. İşte gerçekte olanlar:
Bir uygulamayı çöp kutusuna sürüklerseniz olan şey budur. /Haiku/system/packages
Az önce QtQuickApp'teki dünkü "Merhaba Dünya" uygulamamı çöp kutusuna taşımaya çalıştım. Sistem dizinini taşımayı denemedim, ve tüm paketler sistem dizininde kurulu olduğundan paketi kaldırmak imkansızdır .hpkg değişmeden "onun içerikleri". Sıradan bir kullanıcı korkar ve varsayılan olarak atanan "İptal" düğmesine basar.
açıklar :
Bu yazı 10 yıldan daha eski. Büyük olasılıkla, uyarının yalnızca paketin kendisi taşındığında görünecek şekilde yapılandırmamız gerekir. Normal kullanıcıların bunu yapmasına zaten gerek yok.
Tamam, belki de bunu HaikuDepot'u kullanarak yapmalıyım? Pakete çift tıklıyorum /Haiku/system/packages, “Kaldır” düğmesinin görünmesini bekliyoruz. Hayır, (yalnızca) “Yükle” var. "Kaldır", neredesin?
Sırf eğlence olsun diye, önceden kurulmuş bir pakette "Yükle"ye tıklarsam ne olacağını görmeye çalıştım. Şöyle çıkıyor:
Zaten kurulu bir paketi yüklemeye çalışırsanız bu durum meydana gelir.
Sonraki görünür:
Önceki pencerede "Değişiklikleri uygula"yı tıklarsanız aşağıdaki gibi görünecektir
Bunun bir yazılım hatası olduğunu varsayıyorum; uygulamanın bağlantısı zaten orada. [yazar bir bağlantı sağlamadı - yakl. çevirmen]
Hızlı çözüm: Paket zaten mevcutsa bir "Kaldırma" düğmesi ekleyin
/Haiku/system/packagesveya içinde/Haiku/home/config/packages.
HaikuDepot'ta kurulu paketlerin listesini görüntülerken listede paketimi görüyorum ve kaldırabiliyorum.
Mac bu kategoride kazanır. Ancak doğru kurulumla Haiku'daki kullanıcı deneyiminin Mac'tekinden daha iyi olacağını hayal edebiliyorum. (Geliştiricilerden biri bunu şu şekilde değerlendirdi: "Belirtilen işlevselliği HaikuDepot'a eklemek için bir saatten az bir süre, eğer biraz C++ biliyorsanız", gönüllü olan var mı?)
Paketten bir şeyi çıkarmak
Paketi değil uygulamanın kendisini kaldırmayı deneyelim .hpkg, nereden geldi ("sadece ölümlüler" için herhangi bir fark olduğundan şüpheliyim).
na Mac, kullanıcı aslında genellikle dosyayla çalışır .dmgbaşvuru paketi nereden geliyor .app. Genellikle görüntüler .dmg indirilenler dizininde toplanır ve paketler kullanıcı tarafından /Applications. Pek çok kullanıcının ne yaptığını bilmediğine inanılıyor, bu hipotez eski bir Apple çalışanı tarafından doğrulanıyor. (Mac'te sevmediğim şeylerden biri. Ve örneğin AppImage'da uygulama ile içinde bulunduğu paket arasında hiçbir fark yok. Simgeyi çöp kutusuna sürükleyin = işte bu kadar. Kolay!)
Haiku'daarasında da bir ayrım vardır. apps/ и packages/, bu yüzden bunun kullanıcılar için konuyu daha net hale getirdiğinden şüpheliyim. Ancak bir uygulamayı buradan sürüklerseniz ne olur? apps/ Sepete ekle:
Bir dosyadan alınan bir uygulamayı kaldırmaya çalıştığınızda bu olur .hpkg
Teknik olarak doğrudur (sonuçta uygulama salt okunur bir dosya sisteminde barındırılmaktadır), ancak kullanıcı için özellikle yararlı değildir.
Hızlı çözüm: silmek için GUI'yi kullanmanızı öneririz
.hpkg
Sırf eğlence olsun diye Alt+D tuşlarına basarak uygulamayı kopyalamayı denedim. "Salt okunur bir birimdeki nesneler taşınamıyor veya kopyalanamıyor." mesajını aldım. Ve hepsi çünkü /system (Ayrıca /system/packages и /system/settings) packagefs bağlama noktasıdır (çıktıda nasıl göründüğünü unutmayın) df?). Maalesef komutun çıktısı mount durumu açıklığa kavuşturmuyor (önceki makalelerden birinde söylendiği gibi), mountvolume aradığınızı göstermiyor (görünüşe göre paketler döngü yoluyla monte edilmiş .hpkg "birimler" olarak kabul edilmez ve alternatif komutları da unuttum.
Bu kategoride AppImage dışında kimse kazanmadı (ancak dürüst olmak gerekirse bu önyargılı bir görüş). Ancak, ince ayardan sonra Haiku'daki kullanıcı deneyiminin Mac'tekinden daha iyi olacağı düşünülebilir.
Not: Bir “bölüm” ile ilişkili olarak bir “cildin” ne olduğunu bulmanız gerekir. Bu muhtemelen "klasör" ile "dizin" arasındaki ilişkiye benzer: dizinlerin çoğu dosya yöneticisinde klasörler olarak görünür, ancak hepsi değil (örneğin, dosya olarak değerlendirilen paketler). Bu tür bir gösteri beni resmi bir inek yapar mı?
Bir paketin içeriğini başka bir sisteme kopyalama
na Mac, aptalca paketi sürükledim .appve bağımlılıklar paketin içinde olduğundan birlikte hareket ederler.
Haiku'da, uygulamayı sürüklüyorum ancak bağımlılıklar hiç işlenmiyor.
Hızlı çözüm: Bunun yerine, `.hpkg paketinin tamamını, varsa bağımlılıklarla birlikte sürüklemenizi öneririz.
Mac bu kategoride açıkça kazanıyor. En azından benim için onların paradigmasının aşığı. Bunu Haiku'ya kopyalamalıyım .hpkg uygulama yerine ama sistem bana bunu sunmuyor...
Tüm bağımlılıklarıyla birlikte bir paket indirin
Her makine her zaman ağa bağlı değildir. Tam tersine bazı makineler (evet size bakıyorum, modern Windows, Mac ve Linux) bunu unutuyor. Örneğin bir İnternet kafeye gidebilmem, çıkarılabilir bir sürücüye yazılım indirebilmem, bu sürücüyü ev bilgisayarıma takabilmem ve her şeyin işe yarayacağından emin olabilmem benim için önemli [riskli adam, bunu Windows'ta yapıyor... - yaklaşık. çevirmen].
Sonuç olarak, Windows ve Linux'ta karşılanmayan bağımlılıklarla normalden biraz daha sık karşılaşıyorum.
na Mac bu genellikle tek bir dosyadır, tek yapmanız gereken indirmektir .dmg. Çoğu zaman, MacOS'un kendisi tarafından varsayılan olarak sağlananlar dışında hiçbir bağımlılığı yoktur. Java gibi uygun bir yürütme ortamı gerektiren karmaşık uygulamalar bir istisnadır.
Haiku'da paketi indir .hpkg örneğin Java'daki aynı uygulama yeterli olmayabilir, çünkü hedef makinede Java mevcut olabilir veya olmayabilir. Belirli bir paket için tüm bağımlılıkları indirmenin bir yolu var mı .hpkgHaiku'da varsayılan olarak yüklenen ve dolayısıyla her Haiku sisteminde olması gerekenler dışında?
Mac bu kategoriyi küçük bir farkla kazanıyor.
Yorumlar Sayın :
Bir uygulamanın tüm bağımlılıklarını paketler halinde toplayacak bir program yazmak
.hpkgHaiku'nun iç işleyişine aşina biri için yaklaşık 15 dakika yeterlidir. Eğer gerçekten ihtiyaç varsa buna destek eklemek o kadar da zor değil. Ama benim için bu nadir görülen bir durum.
Bu serideki bir sonraki yazıya kadar nefesimizi tutalım.
Paketleri ayrı bir konuma taşıma
Daha önce de yazdığım gibi paketlerimi yerleştirmek istiyorum .hpkg (iyi veya bunların bir kısmı), önyükleme birimindeki (kök bölüm) olağan yerleşimden ayrı, özel bir yere. Olağan (çok teorik olmayan) durumda, bunun nedeni, ne kadar büyük olursa olsun, (yerleşik) disklerimde sürekli olarak boş alanın tükenmesidir. Ve genellikle uygulamalarımın bulunduğu harici sürücüleri veya ağ paylaşımlarını bağlarım.
na Mac Sadece paketleri taşıyorum .app Finder'da çıkarılabilir bir sürücüye veya ağ dizinine gidin, hepsi bu. Uygulamayı normalde önyükleme biriminden açtığım gibi açmak için hala çift tıklayabilirim. Sadece!
Haiku'da, bana söylendiği gibi, bu benim hareket etmemle başarılabilir. .hpkg paketleri çıkarılabilir bir sürücüye veya ağ dizinine kopyalarsınız, ancak daha sonra bunları sisteme bağlamak için konsoldaki bazı belgelenmemiş komutları kullanmanız gerekir. Bunu yalnızca GUI kullanarak nasıl yapacağımı bilmiyorum.
Mac bu kategoride kazanır.
Bay'a göre. :
Bu normal kullanıma dayalı bir optimizasyondur. Birden fazla kullanıcıdan talep olması durumunda hayata geçireceğiz. Her durumda, üçüncü tarafların uygulama olasılığı vardır.
Bir sonraki makalede bunun hakkında konuşacağız.
Ağ dizinlerinden bahsetmişken, yerel bilgisayara kopyalanabilen veya doğrudan yerel ağdan çalıştırılabilen basit, keşfedilebilir, ağ çapında uygulamalara (Zeroconf gibi) sahip olmak harika olurdu (sanırım LAN partileri). Tabii ki, geliştiriciler aracılığıyla vazgeçme seçeneğine sahipler. app_flags.
hpkg sisteminin GUI ile entegrasyonuna ilişkin nihai rapor
Bunun öncelikle entegrasyonun göreceli yeniliğinden kaynaklandığını düşünüyorum. .hpkg GUI hala arzulanan çok şey bırakıyor. Neyse, UX açısından geliştirilebilecek birkaç şey var...
Bir şey daha: Çekirdek Hata Ayıklama Alanı
Örneğin çekirdek paniği sırasında komut girebilmek harika olurdu. syslog | grep usb. Haiku'da Kernel Debug Land sayesinde bu mümkün. Her şey çekirdek paniğine girmeden olması gerektiği gibi çalışırsa, bu sihri çalışırken nasıl görebilirsiniz? Alt+PrintScn+D (hata ayıklama anımsatıcısı) tuşlarına basarak kolaydır. Hemen hatırlıyorum Bu, orijinal Macintosh geliştiricilerinin hata ayıklayıcıya girmesine izin verdi (tabii ki yüklüyse).
Sonuç
Haiku sisteminin karmaşıklığının, işin küçük bir ekip tarafından, çalışma ortamına net bir şekilde odaklanılarak ve sistemin tüm katmanlarına erişilebilmesiyle yürütülmesi gerçeğinden kaynaklandığını anlamaya başlıyorum.
Her şeyin soyutlamanın üzerine oturduğu ve koltuk değneğiyle hareket ettiği ölçüde her şeyin küçük parçalara bölündüğü Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu dünyasıyla keskin bir tezat.
Ayrıca sistemin nasıl olduğuna dair bir anlayış vardı. .hpkg Snappy, Flatpak, AppImage ve hatta btrfs gibi geleneksel paket yöneticilerinin en iyi uygulamalarını birleştirir ve bunları Mac'in "sadece çalışır" yaklaşımıyla harmanlar.
Sanki kafamda bir şey "değişmiş" gibiydi ve sistemin nasıl çalıştığını anladım. .hpkg sadece ona bakarak nasıl yuvarlanacağını biliyor. Ama mesele ben değilim, sistemin güzelliği ve sadeliği. Bunların çoğu orijinal Mac'in ruhundan ilham alıyor.
Evet, tarayıcıda gezinmek sarsıntılı olabilir ve salyangoz gibi çalışabilir, uygulamalar eksik olabilir (Gtk yok, Electron - geliştiriciler bunların karmaşıklıkla pek iyi gitmediği sonucuna vardı), video ve 3d hızlandırma tamamen eksik olabilir, ancak yine de bu sistemi beğenin. Sonuçta bunlar düzeltilebilir ve er ya da geç ortaya çıkacaklar. Bu sadece zaman meselesi ve belki biraz kırmızı göz.
Yardım edemem ama sanırım bundan sonra başlayacak Haiku yılı masaüstünde.
Rastgele problemler
Belki zaten istekler vardır, yoksa onları açmalı mıyım?
- BeScreenCapture, Peek gibi GIF'e aktarabilmelidir. Bu, Haiku'da zaten mevcut olan ffmpeg kullanılarak yapılabilir. .
- Ekran görüntüsü yazılımı kalıcı bir pencereyi yakalayamıyor, bunun yerine ekranın tamamını yakalıyor
- WonderBrush'un kırpma aracını kullanarak ekran görüntülerini kırpamaz ve ardından sonucu bir dosyaya kaydedemezsiniz.
- Haiku'daki el imlecini özellikle sevmiyorum ama bunun sıcak nostaljik duyguyla ilgisi olduğunu düşünüyorum. Bu, Krita'da kırpma aracını kullanırken özellikle can sıkıcı bir durumdur çünkü hatalı kırpmaya neden olur (bu makaledeki kalıcı diyalogların ekran görüntülerine bakın). Artı işareti imleci harika olurdu. .
Kendin dene! Sonuçta, Haiku projesi DVD veya USB'den önyükleme için oluşturulan görüntüler sağlar . Yüklemek için görüntüyü indirin ve kullanarak bir flash sürücüye yazın.
Sormak istediğiniz bir şey var mı? Sizi Rusça konuşulanlara davet ediyoruz .
Hataya genel bakış:
Itibaren çeviri: Bu Haiku hakkındaki serinin altıncı makalesidir.
Makalelerin listesi:
Kaynak: habr.com