Linux için Uygulama Geliştirme
(makealinux.app)- Linux masaüstü ve mobilde yeni yazılımlara yönelik talep var, ancak uygulama mağazaları ve depolarda uygulama sayısı yetersiz olduğu için mesaj, yeni dağıtımlar yerine uygulama geliştirmeye odaklanmak gerektiği yönünde
- Kişisel bir ihtiyaçtan doğan bir uygulama da açık geliştirme sürecinden geçerse öğrenme kaynağına ve topluluğa dönüşerek Linux ekosisteminin genişlemesine katkı sağlayabilir
- Yüzlerce dağıtımdan oluşan çeşitlilik bir yük olsa da, belgelenmiş paketleme ve dağıtım sistemleri kullanılırsa uygulamalar farklı ortamlardaki kullanıcılara ulaştırılabilir
- GNOME, KDE Frameworks, elementary OS, Electron, Ubuntu Touch; Gtk, Qt, Vala, JavaScript·HTML·CSS, QML gibi farklı geliştirme yolları sunar
- AppCenter, AppImage, Flatpak, Open Build Service, Snapcraft gibi dağıtım araçları bulunur; ayrıca ücretli uygulamalar, hizmetler ve bağış temelli uygulama mağazaları üzerinden gelir elde etme olanağı da vardır
Linux'un neden daha fazla uygulamaya ihtiyacı var
- Masaüstü ve mobil Linux kullanıcılarının yeni yazılımlara yönelik talebi var
- Linux uygulama mağazaları ve depolarında, kapalı platformlara kıyasla daha az uygulama bulunuyor
- Teknoloji meraklılarına, yeni Linux dağıtımları üretmek yerine enerjilerini ve yaratıcılıklarını Linux kullanıcıları için yeni uygulamalar geliştirmeye yöneltmeleri çağrısı yapılıyor
- Temel mesaj şu: “Linux dağıtımı yapmayı bırakın ve uygulama yapın”
Uygulama geliştirmenin ekosisteme etkisi
- Kişisel olarak ihtiyaç duyduğunuz bir uygulama fikri varsa, benzer ihtiyacı duyan başka kullanıcılar da olabilir
- Bir uygulamayı açık şekilde geliştirmek, daha yeni geliştiricilerin de öğrenip başlamasını sağlayarak gelecek nesil Linux uygulama geliştirmeye katkı sunabilir
- Uygulama geliştirme yaratıcı bir iştir; ayrıca projeyi tamamladığınızda hissedilen başarı duygusu da başlı başına bir ödül olabilir
- Uygulama geliştirme topluluk oluşumuna yardımcı olur ve Linux topluluğu çoğu zaman geliştiricilerin başarılı olmasını ister
- Yazılım geliştirme becerileri talep gören yeteneklerdir ve çok sayıda ücretsiz öğrenme kaynağı da vardır
- Linux kullanıcılarının geliştiricileri maddi olarak desteklemediği düşüncesi bir yanılgıdır; popüler ücretli uygulama ve hizmetlerle yeni gelir kaynakları oluşturulabilir
Farklı Linux dağıtımlarını hedeflemek
- Linux, diğer platformlardan farklı olarak çok çeşitli bir hedeftir ve yüzlerce dağıtım vardır
- Bir uygulama yayımlandığında genellikle birden fazla ortamda çalışabilir
- Geliştiricilerin uygulamaları kullanıcılara ulaştırabilmesi için iyi belgelenmiş paketleme ve dağıtım sistemleri vardır
- Her geliştirme çatısı ve Linux dağıtımı, uygulamaları kullanıcılara ulaştırmak için önerilen bir yol sunar
- Uygulamanızı paylaşmaya hazır olduğunuzda, geliştirme belgelerindeki önerilen paketleme rehberlerine bakabilirsiniz
Geliştirmeye başlamak için yollar
-
GNOME
- GNOME projesi GNOME Shell masaüstünü geliştirir ve Gjs ile Gtk tabanlı geliştirmeyi destekler
- Gtk ile Python, C, C++, Rust, JavaScript gibi popüler diller kullanılabilir
- GNOME Developer Center
-
KDE Frameworks
- KDE, Plasma masaüstünü ve uygulama geliştirme araçlarıyla çatılarını sunar
- KDE Frameworks, çeşitli masaüstü uygulamalarının geliştirilmesinde kullanılmıştır
- Ağırlıklı olarak Qt araç takımı ve C++ programlama dili kullanılır
- KDE Frameworks Getting Started
-
elementary OS
- elementary OS, Windows ve macOS'a alternatif hızlı, açık ve gizliliğe saygılı bir işletim sistemi olmayı hedefler
- Geliştiriciler, uygulama geliştirmek için bir masaüstü ve ekosistem inşa eder
- Geliştirici rehberi Vala ve Gtk kullanımını önerir
- elementary OS Developer Guide
-
Electron
- Electron, JavaScript, HTML ve CSS ile çapraz platform masaüstü uygulamaları oluşturmayı mümkün kılar
- Geliştiriciler, geniş node modül kütüphanesinden yararlanarak web teknolojileri tabanlı uygulamalar geliştirebilir
- Electron Documentation
-
Ubuntu Touch
- Ubuntu Touch; telefon, tablet ve PC gibi farklı cihazlarda çalışacak şekilde tasarlanmış açık kaynaklı bir işletim sistemidir
- Yerel Ubuntu Touch uygulamaları QML veya HTML ile oluşturulur; davranışları ise JavaScript, C++, Python, Rust, Go ile tanımlanır
- Ubuntu Touch Documentation
Linux uygulama ekosistemi hakkında geliştirici görüşleri
- GNOME Foundation'dan Neil McGovern, Linux'u geniş kitlelere ulaştırmak için gelişen ve güçlü bir uygulama ekosistemi gerektiğini, herkesin Linux için geliştirme yapabilmesinin açık masaüstü hedefine yaklaşmayı sağlayacağını düşünüyor
- KDE e.V.'den Aleix Pol, Linux'u tercih edilen bir işletim sistemi yapmak için harika uygulamalara ihtiyaç olduğunu ve geliştirme araçlarıyla hayal edilen şeylerin yapılabileceğini söylüyor
- elementary'nin kurucusu Daniel Foré, masaüstü Linux için harika uygulamalar geliştirmenin yanı sıra platform API'leri oluşturma ve masaüstünün yönünü etkileme fırsatı da bulunduğunu düşünüyor
- UBports Foundation yönetim kurulu üyesi Jan Sprinz, Linux uygulama geliştirmenin kapalı ekosistemlerden tamamen farklı olduğunu; teknik olarak rekabet edilse bile daha büyük bir vizyon için birlikte çalışıldığını söylüyor
Uygulama paylaşma ve dağıtma yöntemleri
-
AppCenter
- Bağımsız geliştiriciler için herkese açık, pay-what-you-want modelinde bir uygulama mağazası ve build hizmetidir
- AppCenter Dashboard, GitHub ile entegredir ve sürüm yayımlama ile issue takibini destekler
- AppCenter Dashboard
-
AppImage
- Masaüstü Linux uygulamaları, AppImage biçiminde dağıtılarak yaygın Linux dağıtımlarının kullanıcılarına ulaştırılabilir
- Yaklaşım, bir kez paketleyip her yerde çalıştırma fikrine dayanır
- AppImage Packaging Guide
-
Flatpak
- Linux masaüstü uygulamalarını dağıtmak için bir çatı sunar
- Linux masaüstünde uzun yıllar çalışmış geliştiriciler tarafından oluşturulmuş ve bağımsız bir açık kaynak proje olarak yürütülmektedir
- Flatpak Documentation
-
Open Build Service
- openSUSE Build Service, Open Build Service'in herkese açık örneğidir
- openSUSE dağıtımını geliştirmenin yanı sıra Fedora, Debian, Ubuntu, SUSE Linux Enterprise gibi birçok dağıtım için aynı kaynaktan paket sunmak amacıyla kullanılır
- openSUSE Build Service Help
-
Snapcraft
- Snapcraft, snap oluşturmak için kullanılan bir komut satırı aracıdır
- snap'ler; masaüstü, bulut ve IoT için uygulama paketleridir ve kolay kurulum, güvenlik, çapraz platform desteği ve bağımlılıklardan bağımsızlık sunduğu belirtilir
- Snapcraft Documentation
1 yorum
Hacker News yorumları
Bence varsayım yanlış; çünkü Linux’ta hâlâ ABI açısından kararlı temel framework paketleri yok
Rakip platformlarda CoreImage, CoreAudio, CodeML, SceneKit, AppKit gibi temel framework’ler çok daha fazla ve daha seyrek bozuluyor
Linux’taki snap veya flatpak de ilginç olsa da, uygulamanın kullanmasını istediğiniz framework’ler ve programlama dilinin kendisi içinde çözmek yerine altyapı ve paket yönetimiyle etrafından dolaşmaya daha yakın bir yaklaşım
Linux’ta fiilî standart paketler aslında var, ama değişen ve terk edilen şeyler olduğu için kararlılık daha düşük. Yine de dışarıdan göründüğünden daha iyi ve Snaps ile bazı sorunlar hafifletilebiliyor
Ancak insanlar böyle standartların olmadığı bir dağıtım seçerse, her türlü tuhaf yapılandırmayı desteklemediğiniz anda potansiyel kullanıcıların yarısını kaybediyorsunuz
Ama yazıda söylendiği gibi çoğu kişi dağıtım yapmaya odaklanmayı sürdürüyor ve doğal olarak sayısız tuhaf dağıtımın hepsini takip edecek tek bir stack’in ortaya çıkması zorlaşıyor
Sonunda Google, Linux çekirdeğini alıp üzerine Java ve JavaScript tabanlı iki temel framework paketi koydu; genel tüketiciler açısından kazanan Linux dağıtımları da bunlar oldu
Oyun geliştiricileri genelde en güncel büyük dağıtımlardan birinde derleyip Steam’e yüklüyor; o dağıtımda glibc 2.36 varsa binary de çoğu zaman glibc 2.36 ve üzerini gerektiren sürüm adlarına sahip oluyor
Sonunda binutils gas’ın symver yönergesini kullanıp makul ölçüde eski bir glibc ile uyumlu sürüm adlarını zorla eşleştirmek gerekiyor. Kişisel olarak 5 yılı, belki 7-8 yılı makul bir ölçüt görüyorum: https://sourceware.org/glibc/wiki/Glibc%20Timeline
Sıradan oyun geliştiricileri bu sorunları neredeyse hiç bilmiyor; bilseler bile pazarın %1’i için bu kadar sancılı bir iş yapmayacaklardır. libgcc ve C++ söz konusuysa, bu ABI sorununu önlemek için libstdc++’ı da statik linklemek gerekir
Yine de Godot engine bu noktayı dikkate alan build container’ları sağlıyor; Unity de bu tarafta temiz görünüyor. UT5.x için emin değilim
Buna karşılık Electron tabanlı oyunlar gibi hazırlıksız engine’ler de var. Enlightenment, Qt, saf X11, Wayland gibi dağıtımlara uygun GTK+ sürümü yoksa çalışmayabilirler
Geniş bir ELF/Linux dağıtım yelpazesini hedefleyerek Google Blink engine’in tamamını düzgün paketleyip binary olarak dağıtmak da kolay değil
ELF/Linux, genel ABI kırılmaları nedeniyle yalnızca binary dağıtıma düşmanca davranıyor; bu özellikle SDK ve temel kütüphanelerde belirgin
Oyun binary’leri bile bu kadar zorsa uygulamalar daha da zor olacaktır. Geliştiricilerin sonunda “umurumda değil, Microsoft SUSE GNU/Linux kurup kullanın; geri kalanını desteklemiyorum” diyeceği bir tablo görüyorum
Destek süresi, hangi fork’un daha iyi olduğu, diğer üçüncü taraf kütüphanelerle iyi çalışıp çalışmadığı gibi şeyleri neredeyse hiç düşünmeden hemen kullanabileceğiniz çok sayıda aracın olması harika. Sürtünmeyi ciddi biçimde azaltıp sadece üretmeye başlamanızı sağlıyor
KDE Qt ekosistemi ve GNOME/GTK tarafı buna en yakın olanlar, ama henüz o seviyede değiller
Paket adında
devveversionne zaman eklenmeli, sona eklenen rastgele1ya da0ne anlama geliyor; belki bunun kalıbını bilmiyorumdur ama tutarlı paket adlandırma kurallarına sahip ilk Linux dağıtımının gönülleri kazanacağını düşünüyorumlibgnutls-devlibgtk-3-0libwayland-server0libxcb1libx11-6libffi-devlibncurses5-dev-dev, header dosyalarını içerdiği için oldukça kolay bir kısımSayılar, aynı anda birden fazla sürüm kurulabildiğinde sürümü gösterir. Ancak
xcb1gibi kütüphane adının bir parçası olduğu durumlar istisna olabilirÖrneğin bir noktada
libgtk-3-0ilelibgtk-2-$somethingaynı anda kurulabiliyordu muhtemelen. Sonradanlibgtk-2kaldırılsa bile eski eğitimlerdekilibgtk-3-0referansları bozulmasın diye adı korumuş olmaları çok olasılibwayland-server0sonundaki0ı ben de tam bilmiyorum./var/libaltında aynı kütüphanenin birden fazla.$numberkuyruğuyla durduğunu görüyorum ama bunun tam olarak neyi çözdüğünü hiç kurcalamadım-devolmayan paket yeterlidir; o kütüphaneyle geliştirme yapacaksanız header dosyalarını kuran-devpaketine de ihtiyacınız olurSondaki
1ya da0özel bir şey değil, sadece paket adının veya sürümün bir parçasıdırAncak
-dev, yalnızca o kütüphaneyi hedefleyerek geliştirme yaparken gereken şeyleri ifade ederSayı, ana sürüm numarasıdır; yani uyumluluk numarasıdır. Bu sayede farklı paketlerin bağımlı olduğu birden çok ana sürüm, çakışmadan kolayca birlikte kurulabilir
-devpaketini kurmanız yeterli. Numaralı-devpaketleriyle genelde doğrudan uğraşmanız gerekmez; gerekiyorsa numarasız paketin sizi ona yönlendirmesi beklenirDerleme sırasında hangi numara sonekinin, yani ABI sürümünün kullanıldığı kaydedilir. Bunun
.so.Nsonekiyle aynı olması gerekir ama doğrudan bu şekilde aranmazBu yöntem sayesinde uyumsuz kütüphane kopyalarının birden fazlası kurulabilir ve doğru olanı kullanılabilir. Dağıtımlar genelde büyük sürümlerde eskileri temizler
Kurulum sırasında, derleme sırasında kaydedilen bağımlılıkların otomatik olarak kullanılması gerekir
Bu, Linux platformunun tamamını geride tutan en büyük sorunlardan biri. Sıklıkla avantaj diye anlatılıyor ama ben öyle görmüyorum
Geliştiriciler çok seçenek olmasını Linux’un avantajı diye öne sürüyor, ancak birçok kullanıcı için bu seçim paradoksuna dönüşüyor ve onları eskiden kullandıkları platforma geri döndürüyor
macOS ve Windows’ta seçenekler daha az, ama mevcut seçenekler çok daha cilalı ve daha az parçalanmış durumda
Örneğin kaç tane tiling pencere yöneticisine ihtiyaç var? En iyi tiling pencere yöneticisini seçip daha iyi bir dock ve applet’ler yapılamaz mı? Tiling pencere yöneticisi paradigmasına entegre olan uygulamalar ve launcher’lar ne olacak?
Bunun yerine çoğu zaman 10 farklı tiling pencere yöneticisi ve bunların üzerine eklenmiş yarım yamalak geçici çözümler kalıyor
Başarılı bir ekosistem, göze çarpan seçeneklerden biri seçildiğinde bile yeterince iyi sonuç alınmasını sağlar
Linux dağıtımlarının artması çoğunlukla anlamlı uygunluğu azaltmayan küçük farklardan ibarettir ve bunu sorun olarak görenler, zaten dağıtım seçmekte pek zorlanmayan çok küçük bir azınlıktır
Buna karşılık Wayland gibi durumlarda tesisat ve donanım bir anda önemli hâle gelir; kullanılabilir bir kombinasyon seçmek için iç yapıyı bir miktar bilmek gerekir, bu yüzden gerçek bir soruna dönüşür
Mac veya Windows’u Linux’la karşılaştırmak da pek anlamlı değil. Tüketicilerin %95’i için işletim sistemi ayrı bir ürün değil; bilgisayarın sabit bir özelliği ya da işlevidir
Tüm paket uygunsa o işletim sistemi yüklü bir bilgisayar satın alabilirler, ama kendi Windows veya Mac cihazlarına ayrıca kurmaya çalışmazlar
Memnun olacak kadar teknik bilgisi olan insanlar, 3 Ubuntu türevi ve 2 Arch türevi daha çıksa da pek kafa karışıklığı yaşamaz
Açık kaynak geliştiricisi olmak, hedefleri ve araçları kendiniz belirleyebilmek demektir; ticari yazılım geliştirmede çoğu zaman bu özgürlük yoktur
Pürüzlü taraflar oluşur ama IKEA etkisi devreye girer ve sonunda seversiniz
Herkes aynı yazılımı kullanırsa saldırılara daha açık bir monokültür ekosistemi oluşur. Windows’un virüslerin sık hedefi olmasının nedeni de hedefin büyük ve tutarlı olmasıydı
Sıradan bir kullanıcının Windows makinesine sızdığınızda diğerlerine de benzer şekilde sızabiliyordunuz. Linux’u hedef aldığınızda bu çok daha zor
Üstelik bu özgür yazılım. Birine para verip yaptırmıyorsak bunların çoğu gönüllü faaliyet ve başkalarının gönüllü zamanını nereye harcamaları gerektiğini biz söyleyemeyiz
Bu kadar çok grup varken yine de kimse katılmak istemiyorsa hâkim sosyal yapıya da bakmak gerekir. Proje dışındaki davranışları bile cezalandırmaya imkân veren davranış kurallarını kaldırmak bir başlangıç olabilir
Ayrıca daha neyin iyileştirilmesi gerektiğini de pek bilmiyorum. Ulauncher veya Albert gibi şeyler, diğer platformlarda mümkün olandan çok daha güçlü ve arayüzün nasıl daha iyi yapılabileceğini de bilmiyorum
Yazılımların çoğalması iyi. Ancak sıfırdan yeni bir şey yapmadan önce, mevcut olana katkıda bulunmayı ya da terk edilmiş veya güncel derleyiciler ve donanımlarda derlenip çalışacak şekilde elden geçirilmesi gereken bir projeyi seçmeyi düşünmek nasıl olur diye düşünüyorum
Yeniden canlandırmaya değer uykuda/ölmüş projeler veritabanının bir yerlerde olup olmadığını da merak ediyorum
Başka bir proje de birlikte çalışması zor biri tarafından yönetiliyor olabilir ya da öneri ve yamaları kabul etmeyen bir topluluğa sahip olabilir
Sosyal süreçler ve tıkanmalar, katkı motivasyonunu kaybettirebilir. Herkes kişiliksiz, iyimser bir takım oyuncusu olamaz
Benim için sıfırdan başlamak daha iyi. Çünkü tüm değişkenleri kontrol edebilirim, mevcut sosyal ve teknik altyapıyla uğraşmam gerekmez, fikrimin iyi olduğuna birini ikna etmek zorunda kalmam ve koddan çok tartışma ve münazaraya zaman harcamak istemem
Solo geliştirme deneyimi daha iyi. Çünkü politika ve sosyal süreçlere bağlı değil; takım oyuncusu olmaya çalışmak bana yalnızca acı verdi
İş birliği zahmetli ve zor görünebilir, ama sonuçta sonuç üretme işidir ve terk edilecek projelere harcanan zamandan daha iyi değerlendirilmiş zamandır
Birçok kişi, birden fazla işletim sisteminde uyumlu çalışan uygulamalar yapmak için araçların yetersiz olduğundan şikâyet ediyor, ama katılmıyorum. Electron dışındaki çözümlere bakınca bile seçenekler var
Telegram, Qt kullanarak üç işletim sisteminin tamamına performanslı yerel uygulamalar dağıtıyor
Flutter, üç işletim sistemi ve mobil için yerel koda derleniyor
Kirigami, mobil ve masaüstü hedeflerinin tamamında çalışabilen uygulamalar geliştirmeyi sağlayan bir QtQuick framework'ü
Sadece uygulama yapmak yeterli. Bunu Linux'u suçlamak için bahane etmeye gerek yok
Windows, macOS ve mobilde topluluk ya da ciddi proje neredeyse yok. KDE tarafını küçümsemek istemiyorum ama gerçek bu
Qt Quick lisansı da iOS'ta kolay değil; ticari tarafa gidilirse çok pahalı
Buna karşılık Electron'a büyük şirketler yatırım yapıyor ve çok cilalı prodüksiyon seviyesinde araçlar ortaya koyuyor; devasa bir topluluk ve kütüphane ekosistemi var, üstelik Dart gibi yabancı gelen bir dil de değil
Telegram gerçekten bir seviye daha fazla çaba göstermiş. İstemcisi mükemmel
[0]: https://github.com/overtake/TelegramSwift
Sorun, OSS yazılımlarının piyasa ile rekabet etmeye çalışmayı bile pek denememesinde
OSS yazılım kullananlar UX’in eksik olacağını doğal karşılıyor; pratikte de çoğu zaman öyle oluyor
Sıradan kapalı kaynak yazılımlar, kullanıcının para ödememe riski olduğu için son kullanıcı deneyimini iyileştirecek şekilde uyum sağlıyor; OSS’de ise genelde böyle bir risk yok. Açık kaynağın da son kullanıcıdan gelen riske maruz kalması gerekiyor
Notes[1] ile bunu değiştirmeye çalıştım ama yalnızca reklamla geçinmenin zor olduğunu gördüm. Kanban gibi premium özellikler için ödeme de ekledim, ama uygulama tamamen FOSS olduğu için herkes kaynak koddan kolayca derleyebiliyor
Sonraki uygulamayı[2] yayımlamadan önce kapalı kaynak olarak yürütmeyi düşünüyorum. Emeğimin karşılıksız kalması riskini alamam
Para kazanabilirsem Linux’ta UX odaklı uygulamalara daha fazla yatırım yapabilirim; bunun Linux topluluğuna da faydalı olacağına inanıyorum. Bazı kısımları açık kaynak olarak yayımlayabilirim, uzak gelecekte tamamını da açabilirim
[1] https://github.com/nuttyartist/notes
[2] https://www.get-plume.com
Bu yüzden programı açık kaynak yapmazsan, açık kaynak yapıp bazı kişilerin para ödememesi riskini almaya kıyasla daha fazlasını kaybetme olasılığın yüksek
Kapalı kaynak yazılım kullanmak isteyenlerden çok daha fazla kişinin, para ödeyerek de olsa açık kaynak kullanmak isteyeceğini düşünüyorum
Açık kaynak olması, kodu herkese dağıtman gerektiği anlamına gelmez; para alıyorsan kaynak kodu yalnızca ücretli kullanıcılara verebilirsin. Ancak onların değiştirme ve yeniden dağıtma hakları olur
Açık kaynakla ilgilenmiyorsan Notion veya Evernote kullanırsın. Modern bir açık kaynak not uygulaması arıyorsan Logseq’i öneririm
Birincisi, Notes, Standard Notes’a epey benziyor. Notes’u copyleft OSS kullanarak yaptıysan, içinde yer alan diğer programcıların çalışmalarına telif ödemediğin sürece şikâyet etmek zor bence
İkincisi, ben muhtemelen alışılmadık bir kullanıcıyım. Linux’u 20 yıldan uzun süredir kullanıyorum ama Bash betiği ya da tek satırlık Perl bile doğru dürüst yazamam
Fakat kod yazamadığım ve başkalarının çalışmalarına, ayrıca bunların sağladığı özgürlüğe minnettar olduğum için, başka platformlarda bireylerin genelde harcadığından çok daha fazla parayı yazılıma harcadım
Kaisen ve Debian’ı, FSF’nin temel araçlarını ve Emacs’i, KDE’yi, Mozilla’nın Firefox’unu, Betterbird’ü, Syncthing’i, LaGrange’ı, Joplin’i, ClipTo’yu, SoulSeek’i ve envs.net gibi hizmetleri destekliyorum
Bazılarına yıllık, bazılarına aylık, bazılarına da yalnızca bir kez ödeme yapıyorum
Standard Notes ilk çıktığında 7 yıllık abonelik de satın almıştım, ama yaklaşık iki ay kullanıp memnun kalmayınca bıraktım. Alacritty gibi çok kullandığım ama bağış yöntemi bulamadığım şeyler de var; bu tür durumları en aza indirmeye çalışıyorum
Aslında macOS’un popüler platformlar arasındaki en kötü pencere yöneticilerinden biri olduğunu hissediyorum. Güzel ve kullanımı kolay, ama temel seviyenin ötesinde bir şey yapmak için doğal olarak keşfedilemeyen sihirli komutlar gerekiyor
Elbette herkesin zevki farklı
Premium fiyatı görmek için tıkladım; yıllık bazda makul ama yalnızca aylık abonelik seçeneği görünüyordu, bu yüzden zor geldi
Böyle bir uygulamada premium sürüme ödeme yapmaktansa bağış yapma olasılığım daha yüksek. Obsidian’da bu model iyi işledi
Özelliklere erken erişimin çok büyük bir değer sunduğunu düşünmüyorum, ama çalışmayı desteklemek için para ödeyen çok oldu
Ayrıca kapalı bir çekirdek ürünün etrafında büyük bir açık kaynak ekosistemi bulunmasının, insanlara ödeme yapmak için neden sunduğunu düşünüyorum
Yazıda birkaç örnek olsaydı iyi olurdu
Dağıtım geliştirip de aslında uygulama geliştirmesi gereken biri aklıma pek gelmiyor. Zorlarsam LinuxCNC olabilir mi? Ama onun belirli çekirdek gereksinimleri var, bu yüzden özel bir dağıtım daha uygun olabilir
Türevinin türevi olan dağıtımların yalnızca farklı bir masaüstü ortamı paketleyip dağıtmasını pek anlayamıyorum
“Linux dağıtımı yapmayı bırakın, uygulama yapın” demektense, ne yapıp ne yapmamamız gerektiğini söylemeye çalışan insanları dinlemeyi bırakmak daha iyi bence
Yine de mesajın ve bilginin kendisi iyi
Kişisel olarak “Linux kullanıcıları daha fazla dağıtım istemiyor. Yazılım istiyor” gibi söylerdim. En azından benim için öyle
Kısa süre önce Mac’ten Linux’a geçtim; amacım performansı iyi ikinci el bir cihazı günlük makine olarak kullanmaktı
Daha önce de birkaç makineye Linux kurmuştum ama bu kez mesele basit bir hobi değil
Ubuntu donanımımı ve çevre birimlerimi iyi destekliyor, ancak uygulama mağazası tamamlanmamış ve zorla eklenmiş gibi hissettiriyor. Yine de neredeyse her şey beklediğim gibi çalışıyor
Mint, Debian ve Arch’a da bakmak istiyorum ama Ubuntu düşünülerek yazılmış çok yazılım var gibi göründüğü için temkinliyim
Debian tabanlı bir Mint sürümü de var, ama bu daha çok Ubuntu tarafına kritik biçimde bağımlı kalmamak için bir güvence gibi
Günümüzde alışılmadık bir dağıtım kullansanız bile bu büyük sorun olmuyor. Çünkü varsayılan paket yöneticisi istediğiniz uygulamayı sunmuyorsa AppImage, Flatpak veya Snap kullanabilirsiniz
Arch kullanırken insanların Ubuntu’yu temel alan varsayımlarına alışmak gerekiyordu, ama çoğu zaman bu ayar dosyalarını yamamak ya da ortam değişkenlerini ayarlamak kadar basitti
Bunlar faydalı ve başka yerlere de aktarılabilir beceriler
Daha önce denemiş olmayı isterdim
İnsan neden böyle bir şey yapsın ki? Daha zor ve Linux kullanıcıları para etmeyen şeylere para ödemez