Başka bir şey: Haiku uygulama paketleri mi?

TL; DR: Haiku, uygulama dizinleri (gibi) gibi uygulama paketleri için uygun desteği alabilir mi? .app Mac'te) ve/veya uygulama görüntüleri (Linux AppImage)? Altyapının çoğu zaten mevcut olduğundan, bunun diğer sistemlerden daha doğru bir şekilde uygulanması daha kolay olan değerli bir eklenti olacağını düşünüyorum.

Bir hafta önce Beklenmedik derecede iyi bir sistem olan Haiku'yu keşfettim. Uzun zamandır dizinlere ve uygulama görsellerine (Macintosh'un basitliğinden esinlenerek) ilgi duyduğum için aklıma bir fikrin gelmesi şaşırtıcı değil...

Tam olarak anlaşılması için, Mac basitliğini hedefleyen ve uygulama yazarlarına ve son kullanıcılara tam kontrol sağlayan bir Linux uygulama dağıtım formatı olan AppImage'ın yaratıcısı ve yazarıyım (daha fazla bilgi edinmek istiyorsanız bkz. wiki и belgeleme).

Haiku için bir AppImage yaparsak ne olur?

Tamamen teorik olarak biraz düşünelim: elde etmek için ne yapılması gerekiyor? AppImageveya Haiku'da buna benzer bir şey mi var? Şu anda bir şey yaratmaya gerek yok çünkü Haiku'da zaten var olan sistem harika çalışıyor ama hayali bir deney güzel olurdu. Bu aynı zamanda, bu tür şeylerin son derece zor olduğu Linux masaüstü ortamlarıyla karşılaştırıldığında Haiku'nun karmaşıklığını da ortaya koyuyor (bunu söylemeye hakkım var: 10 yıldır hata ayıklamayla uğraşıyorum).

Macintosh Sistem 1'de her uygulama Finder'da "yönetilen" ayrı bir dosyaydı. AppImage'ı kullanarak aynı kullanıcı deneyimini Linux'ta yeniden yaratmaya çalışıyorum.

Öncelikle AppImage nedir? Bu, üçüncü taraf uygulamaları yayınlamaya yönelik bir sistemdir (örneğin, Ultimaker Kür), uygulamaların istedikleri zaman ve nasıl yayınlanmalarına izin verir: çeşitli dağıtımların özelliklerini bilmeye, politikalar oluşturmaya veya altyapı oluşturmaya gerek yoktur, bakımcı desteğine gerek yoktur ve kullanıcılara neyi (yükleyemeyeceklerini) söylemezler. bilgisayarlarında. AppImage formatındaki Mac paketine benzer bir şey olarak anlaşılmalıdır. .app disk görüntüsünün içinde .dmg. Temel fark, uygulamaların kopyalanmaması, Haiku paketlerinde olduğu gibi sonsuza kadar AppImage'ın içinde kalmasıdır. .hpkg monte edilmiş ve asla alışılagelmiş anlamda kurulmamıştır.

10 yılı aşkın varlığı boyunca, AppImage bir miktar çekicilik ve popülerlik kazandı: Linus Torvalds bunu açıkça onayladı ve ortak projeler (örneğin, LibreOffice, Krita, Inkscape, Scribus, ImageMagick) bunu ana yol olarak benimsedi. Yüklü veya kaldırılmış kullanıcı uygulamalarına müdahale etmeden sürekli veya gecelik yapıları dağıtmak. Bununla birlikte, Linux masaüstü ortamları ve dağıtımları çoğunlukla hala geleneksel, merkezi bakımcı tabanlı dağıtım modeline bağlı kalmakta ve/veya kendi kurumsal iş ve/veya mühendislik programlarını temel alarak teşvik etmektedir. Flatpak (RedHat, Fedora, GNOME) ve Çabuk (Kanonik, Ubuntu). Gelir gülünç bir şekilde.

O nasıl çalışır

• Her AppImage 2 parça içerir: küçük bir çift tıklama ELF (sözde. runtime.c), ardından bir dosya sistemi görüntüsü gelir SquashFS'e.

• SquashFS dosya sistemi, uygulamanın yükünü ve onu çalıştırmak için gereken her şeyi içerir; bu, doğru bir yaklaşımla, oldukça yeni olan her hedef sistem (Linux dağıtımı) için varsayılan kurulumun bir parçası olarak düşünülemez. Ayrıca uygulama adı, simgeler, MIME türleri vb. gibi meta verileri de içerir.

• Kullanıcı tarafından çalıştırıldığında çalışma zamanı, dosya sistemini bağlamak için FUSE ve squashfuse'u kullanır ve ardından bağlı AppImage içinde bazı giriş noktalarının (diğer adıyla AppRun) çalıştırılmasını yönetir.
  İşlem tamamlandıktan sonra dosya sisteminin bağlantısı kesilir.

Görünüşe göre her şey basit.

Ve bunlar her şeyi karmaşık hale getiriyor:

• Bu kadar çeşitli Linux dağıtımları varken, "doğru akılda olan" hiçbir şeye "her yeni hedef sistem için varsayılan kurulumun parçası" denemez. Bu soruna çözüm üreterek çalışıyoruz dışlama listesi, AppImage'da neyin paketleneceğini ve neyin başka bir yere götürülmesi gerektiğini belirlemenize olanak tanır. Aynı zamanda, genel olarak her şeyin harika çalışmasına rağmen bazen özlüyoruz. Bu nedenle paket oluşturucuların AppImages'ı tüm hedef sistemlerde (dağıtımlarda) test etmelerini öneririz.
• Uygulama verilerinin dosya sistemi genelinde yeniden konumlandırılabilmesi gerekir. Ne yazık ki birçok uygulamanın, örneğin kaynaklara giden sabit kodlanmış mutlak yolları vardır. /usr/share. Bunun bir şekilde düzeltilmesi gerekiyor. Ayrıca, ihracat yapmanız gerekir LD_LIBRARY_PATH, veya düzelt rpath böylece yükleyici ilgili kütüphaneleri bulabilir. İlk yöntemin dezavantajları vardır (bunların üstesinden karmaşık yollarla gelinir), ikincisi ise oldukça zahmetlidir.
• Kullanıcılar için en büyük UX tuzağı, yürütülebilir biti ayarla AppImage dosyasını indirdikten sonra. İster inanın ister inanmayın, bu bazıları için gerçek bir engeldir. Yürütülebilirlik bitini ayarlama ihtiyacı deneyimli kullanıcılar için bile zahmetlidir. Geçici bir çözüm olarak, AppImage dosyalarını izleyen ve yürütülebilirlik bitlerini ayarlayan küçük bir hizmet kurmanızı önerdik. Saf haliyle, kutudan çıktığı gibi işe yaramayacağı için en iyi çözüm değildir. Linux dağıtımları bu hizmeti sağlamadığından kullanıcılar kötü bir deneyim yaşarlar.
• Linux kullanıcıları yeni bir uygulamanın başlangıç ​​menüsünde bir simgeye sahip olmasını bekler. Sisteme “Bakın yeni bir uygulama var, çalışalım” diyemezsiniz. Bunun yerine, XDG spesifikasyonuna göre dosyayı kopyalamanız gerekir. .desktop içinde doğru yere /usr sistem çapında kurulum için veya $HOME bireysel için. XDG spesifikasyonuna göre belirli boyutlardaki simgelerin belirli yerlere yerleştirilmesi gerekir. usr veya $HOMEve ardından simge önbelleğini güncellemek için çalışma ortamında komutları çalıştırın veya çalışma ortamı yöneticisinin bunu çözeceğini ve her şeyi otomatik olarak algılayacağını umun. MIME türleriyle aynı. Geçici bir çözüm olarak, yürütülebilirlik bayrağını ayarlamanın yanı sıra simgeler vb. varsa aynı hizmetin kullanılması önerilmektedir. AppImage'da bunları AppImage'dan XDG'ye göre doğru yerlere kopyalayın. Silindiğinde veya taşındığında hizmetin her şeyi temizlemesi beklenir. Elbette her çalışma ortamının davranışında, grafik dosya formatlarında, boyutlarında, depolama konumlarında ve önbellekleri güncelleme yöntemlerinde farklılıklar vardır ve bu da sorun yaratır. Kısacası bu yöntem bir koltuk değneğidir.
• Yukarıdakiler yeterli değilse, dosya yöneticisinde hala AppImage simgesi yoktur. Linux dünyası henüz elficon'u uygulamaya karar vermedi (her ne kadar tartışma и uygulama), dolayısıyla simgeyi doğrudan uygulamaya yerleştirmek imkansızdır. Böylece, dosya yöneticisindeki uygulamaların kendi simgelerinin olmadığı (fark yok, AppImage veya başka bir şey yok), yalnızca başlat menüsünde oldukları ortaya çıktı. Geçici bir çözüm olarak, başlangıçta masaüstü yöneticilerinin grafik dosyalarının küçük resim önizleme görüntülerini simgeler olarak göstermesine olanak tanıyan bir mekanizma olan küçük resimleri kullanıyoruz. Sonuç olarak, yürütülebilirlik bitini ayarlama hizmeti aynı zamanda bir "minyatürleştirici" olarak da çalışarak simge küçük resimlerini oluşturup uygun konumlara yazıyor /usr и $HOME. Bu hizmet ayrıca AppImage'ın silinmesi veya taşınması durumunda da temizleme gerçekleştirir. Her masaüstü yöneticisinin biraz farklı davranması nedeniyle, örneğin simgeleri hangi formatlarda, hangi boyutlarda veya yerlerde kabul ettiği gibi, bunların hepsi gerçekten acı verici.
• Hatalar meydana gelirse uygulama yürütme sırasında çöker (örneğin, temel sistemin parçası olmayan ve AppImage'da sağlanmayan bir kitaplık vardır) ve GUI'de kullanıcıya tam olarak ne olduğunu söyleyen kimse yoktur. Bunu kullanarak bu sorunu aşmaya başladık. ihbar Bu, komut satırından hataları yakalamamız, bunları kullanıcının anlayabileceği mesajlara dönüştürmemiz ve daha sonra masaüstünde görüntülenmesi gerektiği anlamına gelir. Ve elbette her masaüstü ortamı bunları biraz farklı şekilde ele alır.
• Şu anda (Eylül 2019 - çevirmenin notu) sisteme dosyanın gerekli olduğunu söylemenin basit bir yolunu bulamadım. 1.png Krita kullanılarak açılmalı ve 2.png - GIMP'i kullanarak.

Kullanılan çapraz masaüstü spesifikasyonları için depolama konumu GNOME, KDE и Xfce freedesktop.org

Haiku çalışma ortamının derinlerine işlemiş olan karmaşıklık düzeyine ulaşmak, teknik özelliklerden dolayı imkansız olmasa da zordur. freedesktop.org'dan XDG çapraz masaüstü için ve bu spesifikasyonlara dayalı masaüstü yöneticilerinin uygulamaları için. Örnek olarak, sistem genelindeki bir Firefox simgesinden bahsedebiliriz: görünüşe göre, XDG'nin yazarları, bir kullanıcının aynı uygulamanın birkaç sürümünün yüklü olabileceğini bile düşünmemişlerdi.

Firefox'un farklı sürümleri için simgeler

Sistem entegrasyonunu bozmamak için Linux dünyasının Mac OS X'ten neler öğrenebileceğini merak ediyordum. Eğer vaktiniz varsa ve bu konuyla ilgileniyorsanız, ilk Mac OS X mühendislerinden biri olan Arnaud Gurdol'un söylediklerini mutlaka okuyun:

Uygulamanın kurulumunu, uygulama simgesini bir yerden (sunucu, harici sürücü) bilgisayarınızın sürücüsüne sürüklemek kadar kolay hale getirmek istedik. Bunu yapmak için uygulama paketi, simgeler, sürüm, işlenen dosya türü, sistemin uygulamayı işlemek için bilmesi gereken URL şemalarının türü de dahil olmak üzere tüm bilgileri saklar. Bu aynı zamanda Icon Services ve Launch Services veritabanındaki 'merkezi depolama' bilgilerini de içerir. Performansı desteklemek için uygulamalar birkaç 'iyi bilinen' yerde 'keşfedilir': sistem ve kullanıcı Uygulamaları dizinleri ve kullanıcı uygulamayı içeren dizindeki Finder'a gittiğinde otomatik olarak diğerleri. Uygulamada bu çok işe yaradı.

https://youtu.be/qQsnqWJ8D2c
Apple WWDC 2000 oturum 144 - Mac OS X: uygulamaları paketleme ve belgeleri yazdırma.

Linux masaüstlerinde bu altyapıya benzer bir şey yok, bu nedenle AppImage projesindeki yapısal sınırlamalara geçici çözümler arıyoruz.

Haiku kurtarmaya mı geliyor?

Ve bir şey daha: Masaüstü ortamlarının temeli olan Linux platformları o kadar az belirtilme eğilimindedir ki, tutarlı bir tam yığın sistemde oldukça basit olan birçok şey, Linux'ta sinir bozucu derecede parçalanmış ve karmaşıktır. Raporun tamamını masaüstü ortamları için Linux platformuyla ilgili konulara adadım (bilgili geliştiriciler her şeyin çok uzun süre bu şekilde kalacağını doğruladılar).

2018'de Linux masaüstü ortamlarının sorunlarına ilişkin raporum

Linus Torvalds bile çalışma alanı fikrinin başarısız olmasının nedeninin parçalanma olduğunu kabul etti.

Haiku'yu görmek güzel!

Haiku her şeyi inanılmaz derecede basitleştiriyor

AppImage'ı Haiku'ya "taşımak" konusundaki naif yaklaşım, bileşenlerini (çoğunlukla runtime.c ve servis) oluşturmaya çalışmak olsa da (ki bu mümkün bile olabilir!), bu Haiku'ya pek bir fayda sağlamayacaktır. Çünkü aslında Haiku'da bu sorunların çoğu çözülmüş durumda ve kavramsal olarak sağlam. Haiku, uzun zamandır Linux masaüstü ortamlarında aradığım ve orada olmadığına inanamadığım sistem altyapısı yapı taşlarını tam olarak sağlıyor. Yani:

İster inanın ister inanmayın, bu birçok Linux kullanıcısının üstesinden gelemeyeceği bir şeydir. Haiku'da her şey otomatik olarak yapılır!

• Yürütülebilirlik biti olmayan ELF dosyaları, dosya yöneticisinde çift tıklandığında otomatik olarak bir bit alır.
• Uygulamalar, dosya yöneticisinde görüntülenen simgeler gibi yerleşik kaynaklara sahip olabilir. Bir sürü resmi simgeler içeren özel dizinlere kopyalamaya gerek yoktur ve dolayısıyla uygulamayı sildikten veya taşıdıktan sonra bunları temizlemeye gerek yoktur.
• Uygulamaları belgelere bağlamak için bir veritabanı var, bunun için herhangi bir dosya kopyalamaya gerek yok.
• Çalıştırılabilir dosyanın yanındaki lib/ dizininde, kütüphaneler varsayılan olarak aranır.
• Çok sayıda dağıtım ve masaüstü ortamı yoktur; ne işe yararsa, her yerde çalışır.
• Uygulamalar dizininden farklı çalıştırılacak ayrı bir modül yoktur.
• Uygulamaların kaynaklarına giden yerleşik mutlak yolları yoktur; çalışma zamanında konumu belirlemek için özel işlevlere sahiptirler.
• Sıkıştırılmış dosya sistemi görüntüleri fikri ortaya atıldı: bu herhangi bir hpkg paketidir. Hepsi çekirdek tarafından monte edilir.
• Aksini açıkça belirtmediğiniz sürece her dosya, onu oluşturan uygulama tarafından açılır. Bu ne kadar harika!

İki png dosyası. Çift tıklandığında farklı uygulamalar tarafından açılacağını belirten farklı simgelere dikkat edin. Ayrıca kullanıcının bireysel bir uygulamayı seçebileceği "Birlikte aç:" açılır menüsüne de dikkat edin. Ne kadar basit!

Görünüşe göre Linux'ta AppImage'ın gerektirdiği desteklerin ve geçici çözümlerin çoğu, ihtiyaçlarımızın çoğunu karşılamasını sağlayan basitlik ve gelişmişliği özünde barındıran Haiku'da gereksiz hale geliyor.

Sonuçta Haiku'nun uygulama paketlerine ihtiyacı var mı?

Bu büyük bir soruya yol açıyor. Haiku'da AppImage gibi bir sistem oluşturmak Linux'tan çok daha kolay olsaydı, bunu yapmaya değer miydi? Yoksa Haiku, hpkg paket sistemiyle böyle bir fikri geliştirme ihtiyacını etkili bir şekilde ortadan kaldırdı mı? Cevap vermek için AppImages'ın varlığının ardındaki motivasyona bakmamız gerekiyor.

Kullanıcının bakış açısı

Son kullanıcımıza bakalım:

• Yönetici (root) şifresi istemeden uygulama yüklemek istiyorum. Haiku'da yönetici kavramı yoktur, kişisel bir sistem olduğu için tüm kontrol kullanıcıya aittir! (Prensip olarak bunu çok oyunculu modda hayal edebilirsiniz, umarım geliştiriciler bunu basit tutar)
• Uygulamaların en son ve en iyi sürümlerini dağıtımımda görünmelerini beklemeden almak istiyorum (en azından tüm işletim sistemini güncellemediğim sürece çoğu zaman bu "asla" anlamına gelir). Haiku'da bu durum değişken sürümlerle "çözülmektedir". Bu, uygulamaların en yeni ve en iyi sürümlerini edinmenin mümkün olduğu anlamına gelir, ancak bunu yapabilmek için sistemin geri kalanını sürekli olarak güncellemeniz ve onu etkili bir şekilde "hareketli bir hedefe" dönüştürmeniz gerekir..
• En son sürümde neyin bozuk olduğunu bilmenin bir yolu olmadığından veya örneğin bir web geliştiricisi olarak çalışmamı tarayıcının farklı sürümleri altında test etmem gerektiğinden, aynı uygulamanın birkaç sürümünü yan yana istiyorum. Haiku ilk sorunu çözüyor ama ikinciyi çözemiyor. Güncellemeler geri alınıyor, ancak yalnızca sistemin tamamı için; örneğin WebPositive veya LibreOffice'in birkaç sürümünü aynı anda çalıştırmak (bildiğim kadarıyla) imkansızdır.

Geliştiricilerden biri şöyle yazıyor:

Temelde mantık şudur: Kullanım durumu o kadar nadirdir ki, bunun için optimizasyon yapmak mantıklı değildir; HaikuPorts'ta bunu özel bir durum olarak ele almak fazlasıyla kabul edilebilir görünüyor.

• Uygulamaları başlangıç ​​sürücümde değil, sevdiğim yerde tutmam gerekiyor. Çoğu zaman disk alanım yetersiz kalıyor, bu nedenle uygulamaları (indirdiğim tüm sürümler) depolamak için harici bir sürücüye veya ağ dizinine bağlanmam gerekiyor. Böyle bir sürücüyü bağlarsam uygulamaların çift tıklatılarak başlatılmasına ihtiyacım var. Haiku, paketlerin eski sürümlerini kaydediyor, ancak bunları harici bir sürücüye nasıl taşıyacağımı veya uygulamaları daha sonra oradan nasıl başlatacağımı bilmiyorum.

Geliştirici yorumu:

Teknik olarak bu zaten mount komutuyla mümkün. Elbette yeterli sayıda ilgilenen kullanıcımız olur olmaz bunun için bir GUI oluşturacağız.

• Kendi kendime manuel olarak yönetemediğim, dosya sistemi geneline dağılmış milyonlarca dosyaya ihtiyacım yok. Uygulama başına kolayca indirebileceğim, taşıyabileceğim, silebileceğim bir dosya istiyorum. Haiku'da bu sorun paketler kullanılarak çözülür .hpkgörneğin python'u binlerce dosyadan tek bir dosyaya aktaran. Ancak örneğin python kullanan Scribus varsa, o zaman en az iki dosyayla uğraşmam gerekiyor. Ve bunların birbirleriyle çalışan versiyonlarını saklamaya dikkat etmem gerekiyor.

Aynı Linux'ta yan yana çalışan AppImages'ın birden çok sürümü

Bir uygulama geliştiricisinin bakış açısı

Bir uygulama geliştiricisinin bakış açısından bakalım:

• Kullanıcı deneyiminin tamamını kontrol etmek istiyorum. Uygulamaları ne zaman ve nasıl yayınlamam gerektiğini bana söylemesi için bir işletim sistemine bağlı kalmak istemiyorum. Haiku, geliştiricilerin kendi hpkg depolarıyla çalışmasına olanak tanır, ancak bu, kullanıcıların bunları manuel olarak ayarlamaları gerektiği anlamına gelir ve bu da fikri "daha az çekici" hale getirir.
• Web sitemde dağıtımını yaptığım bir indirme sayfam var .exe pencereler için, .dmg Mac için ve .AppImage Linux için. Ya da belki bu sayfaya erişimden para kazanmak istiyorum, her şey mümkün mü? Haiku için oraya ne koymalıyım? Dosya yeterli .hpkg yalnızca HaikuPorts'tan bağımlılıklarla
• Yazılımım başka yazılımların belirli sürümlerini gerektiriyor. Örneğin, Krita'nın, en azından yamalar Qt'ye geri gönderilene kadar, Krita'nın belirli bir sürümüne ince ayar yapılmış Qt'nin yamalı bir sürümünü veya Qt'yi gerektirdiği bilinmektedir. Uygulamanız için kendi Qt'nizi bir pakette paketleyebilirsiniz .hpkg, ancak büyük olasılıkla bu hoş karşılanmıyor.

Düzenli uygulama indirme sayfası. Haiku için buraya ne yazmalıyım?

Will paketleri (AppDir veya gibi uygulama dizinleri olarak bulunur) .app Apple tarzında) ve/veya görseller (büyük ölçüde değiştirilmiş AppImages biçiminde veya .dmg Apple'dan) uygulamalar Haiku masaüstü ortamına faydalı bir eklenti mi? Yoksa resmin tamamını sulandırıp parçalanmaya ve dolayısıyla karmaşıklığa mı yol açacak? Kararsızım: Bir yandan Haiku'nun güzelliği ve karmaşıklığı, bir şeyi yapmanın birçok yolu yerine genellikle tek bir yolu olduğu gerçeğine dayanıyor. Öte yandan, kataloglar ve/veya uygulama paketleri için altyapının çoğu zaten mevcut olduğundan sistem, kalan yüzde birkaçının da yerine oturması için haykırıyor.

Geliştiriciye göre Bay. paytak paytak sıçrama

Linux'ta onlar (kataloglar ve uygulama kitleri, - yakl. çevirmen) büyük olasılıkla sistemik sorunlara teknik bir çözümdür. Haiku'da biz sistem sorunlarını basitçe çözmeyi tercih ediyoruz.

Sen ne düşünüyorsun

Cevap vermeden önce...

Durun, hızlı bir gerçeklik kontrolü yapalım: aslında uygulama dizinleri - zaten Haiku'nun bir parçası:

Uygulama dizinleri Haiku'da zaten mevcut ancak dosya yöneticisinde henüz desteklenmiyor

Macintosh Finder kadar iyi desteklenmiyorlar. QtCreator dizininin sol üst köşesinde bir "QtCreator" adı ve simgesi olsaydı, çift tıklandığında uygulamayı başlatsaydı ne kadar harika olurdu?

Biraz erken ben zaten diye sordu:

Tüm uygulama mağazaları ve dağıtım depoları onları ve bağımlılıklarını unutmuşken, on yıllık uygulamalarınızı bugün çalıştırabileceğinizden emin misiniz? Gelecekte mevcut işinize erişebileceğinizden emin misiniz?

Haiku'dan zaten bir yanıt var mı, yoksa kataloglar ve uygulama paketleri burada yardımcı olabilir mi? Bence yapabilirler.

Bay'a göre. :

Evet, sorunun cevabı bizde: Birileri dosya formatlarını doğru şekilde okuyabilene veya birebir işlevsellik sağlayana kadar bu uygulamaları gerektiği kadar destekleyeceğiz. Haiku'da BeOS R5 uygulamalarını destekleme taahhüdümüz bunun kanıtıdır...

Bu kesin!

Haiku'nun nasıl bir hareket tarzı izlemesi gerekiyor?

hpkg, dizinler ve uygulama görsellerinin barış içinde bir arada var olabileceğini hayal edebiliyorum:

• Sistem yazılımı kullanımları .hpkg
• En sık kullanılan yazılımlar için (özellikle sürekli sürümleri planlamaya ihtiyaç duyanlar için) şunu kullanın: .hpkg (tüm vakaların yaklaşık %80’i)
• Bazıları aracılığıyla yüklendi .hpkguygulamalar bir uygulama dizini altyapısına (örn. QtCreator) geçmenin faydasını görecektir: şu şekilde dağıtılacaktır: .hpkg, eskisi gibi.

Bay. waddlesplash şunu yazıyor:

İhtiyacınız olan tek şey uygulamaları görüntülemekse /system/appsbunun yerine Masaüstü Çubuğundaki dizinleri kullanıcılar için daha kolay yönetilebilir hale getirmeliyiz, çünkü /system/apps kullanıcılar tarafından düzenli olarak açılıp görüntülenmesi amaçlanmamıştır (MacOS'tan farklı olarak). Bu tür durumlar için Haiku'nun farklı bir paradigması vardır, ancak bu seçenek teoride kabul edilebilir.

• Haiku, uygulama görüntülerini, gecelik, sürekli ve test sürümlerini çalıştırmanın yanı sıra, kullanıcının özel ve dahili yazılımlar ve diğer özel kullanım durumları için "zamanında dondurmak" istediği durumlar için altyapıyı alır (yaklaşık %20) hepsinden). Bu görüntüler uygulamayı çalıştırmak için gerekli dosyaları içerir .hpkg, sistem tarafından takılır ve uygulama tamamlandıktan sonra bağlantısı kesilir. (Belki bir dosya yöneticisi dosyaları .hpkg otomatik olarak veya kullanıcının isteği üzerine uygulama görüntülerine aktarılır; örneğin, bir uygulamayı bir ağ dizinine veya harici sürücüye sürüklediğinizde. Bu sadece bir şarkı! Daha doğrusu şiir - haiku.) Öte yandan, kullanıcı görüntünün içeriğini dosyalar biçiminde yüklemek isteyebilir..hpkg, ardından HaikuDepot aracılığıyla yüklenmiş gibi güncellenecek ve işlenecekler... Beyin fırtınası yapmamız gerekiyor).

mr adlı üyeden alıntı Waddlesplash:

Uygulamaları harici sürücülerden veya ağ dizinlerinden çalıştırmak potansiyel olarak yararlı olabilir. Ve pkgman için daha fazla "bölge" yapılandırma yeteneğinin eklenmesi kesinlikle güzel bir özellik olacaktır.

Böyle bir sistem hpkg'den, dizinlerden ve uygulama görüntülerinden yararlanacaktır. Bireysel olarak iyiler ama birlikte yenilmez olacaklar.

Sonuç

Haiku, PC için basit ve gelişmiş bir kullanıcı deneyimi sağlayan ve genellikle Linux PC için sağlananın çok ötesine geçen bir çerçeveye sahiptir. Paket sistemi .hpkg bu örneklerden biri, ancak sistemin geri kalanı da çok yönlülükle dolu. Ancak Haiku, uygun dizin ve uygulama görüntüsü desteğinden faydalanacaktır. Bunun en iyi nasıl yapılacağı Haiku'yu, onun felsefesini ve mimarisini benden çok daha iyi bilen insanlarla tartışmaya değer. Sonuçta Haiku'yu bir haftadan biraz fazla süredir kullanıyorum. Yine de Haiku tasarımcılarının, geliştiricilerinin ve mimarlarının bu yeni perspektiften yararlanacağına inanıyorum. En azından onların "idman partneri" olmaktan mutlu olurum. Linux uygulama katalogları ve paketleri konusunda 10 yıldan fazla uygulamalı deneyimim var ve Haiku'da bunlar için mükemmel bir uyum olduğunu düşündüğüm bir kullanım alanı bulmak istiyorum. Önerdiğim potansiyel çözümler, tanımladığım sorunlar için kesinlikle tek doğru çözümler değildir ve eğer Haiku ekibi başka, daha şık çözümler bulmaya karar verirse, ben de buna tamamen katılıyorum. Temel olarak, zaten bir sistemin nasıl yapılacağı fikrini düşünüyorum hpkg çalışma şeklini değiştirmeden daha da şaşırtıcı. Haiku ekibinin bir paket yönetim sistemini uygularken uzun süredir uygulama paketleri üzerine düşündüğü ortaya çıktı, ancak ne yazık ki (sanırım) bu fikir "modası geçmiş" hale geldi. Belki onu yeniden canlandırmanın zamanı gelmiştir?

Kendin dene! Sonuçta, Haiku projesi DVD veya USB'den önyükleme için oluşturulan görüntüler sağlar günlük.
Sormak istediğiniz bir şey var mı? Sizi Rusça konuşulanlara davet ediyoruz telgraf kanalı.

Hataya genel bakış: C ve C++'da kendinizi ayağınızdan nasıl vurursunuz? Haiku OS tarif koleksiyonu

Itibaren yazar çeviri: Bu, Haiku hakkındaki serinin sekizinci ve son makalesidir.

Makalelerin listesi: ilk İkinci Üçüncü Dördüncü beşinci altıncı yedinci

Ankete sadece kayıtlı kullanıcılar katılabilir. Giriş yapLütfen.

hpkg sistemini Linux'a taşımak mantıklı mı?

• Evet

• Hayır

• Zaten uygulandı, yorumlara yazacağım

20 kullanıcı oy kullandı. 5 kişi çekimser kaldı.

Kaynak: habr.com